Canvas editor

Design workflows on the Flowker Canvas by dragging Trigger, Executor Call, Conditional, and Action nodes, then connecting and configuring each one.

The Workflow Canvas is a visual drag-and-drop editor for designing workflows in Flowker. It provides an interactive surface where you can add, connect, and configure nodes to define the execution flow of your automated processes.

Accessing the Canvas

---

The canvas opens automatically when you create or edit a workflow. Navigate to Flowker → Workflows, then either create a new workflow or click Edit Workflow on an existing one.

Canvas basics

---

The canvas provides the following interactions:

• Pan — click and drag on the canvas background to move around.
• Zoom — use the scroll wheel or pinch gesture to zoom in and out.
• Select — click a node to select it and view its summary.
• Configure — double-click a node to open its configuration panel on the right side.
• Connect — drag from a node’s output handle to another node’s input handle to create a connection.
• Delete — select a node or connection and press the delete key, or use the context menu.

Node types

---

Flowker workflows are composed of four node types, each serving a distinct role in the execution flow.

Trigger Node

The Trigger Node defines the event that starts the workflow. An active workflow must have at least one trigger node; a draft workflow may be empty or omit a trigger while you design it, but node-level save validation still applies.

When you double-click a trigger node, the Configure Trigger panel opens with the following fields:

Field	Description
Name	A descriptive label for the trigger (e.g., “Webhook Trigger”).
Trigger	A dropdown to select which trigger type to use. Options are loaded dynamically from the Flowker catalog.

After selecting a trigger type, additional configuration fields may appear based on the trigger’s schema. For the webhook trigger, those fields are the path, the method and the input contract — see Configuring a webhook trigger for what each contract accepts. For the schedule trigger, they are the cron expression, the timezone and the enabled flag — see Running a workflow on a schedule.

Available trigger types include:

Trigger	Description
Webhook	The workflow starts when Flowker receives an external HTTP request at the configured path and method.
Schedule	The workflow starts on a time-based schedule defined by a standard 5-field cron expression (minimum granularity of 1 minute), with an optional IANA timezone (defaults to UTC).

Trigger types are loaded from the Flowker catalog and may vary depending on your environment’s configuration. The list above reflects the default available triggers.

Executor Call Node

Executor Call Nodes perform specific operations by calling executors registered in the Flowker catalog. Each executor represents a pre-built integration with Lerian products or external services.

When you double-click an executor call node, the Configure Executor Call panel opens. Its first two fields form a cascade: the provider configuration you pick first decides which executors the second field offers.

Field	Description
Provider	The first field, and the one that sets the connection. It lists the provider configurations saved on the Providers page, each shown by its name with its catalog provider beside it. Picking one binds the step to that connection — its base URL and credentials — and scopes the Executor dropdown below to the same provider. When the organization has no provider configuration yet, the dropdown shows No connections yet — create one in Flowker → Providers. A workflow does not save while an executor call node has no provider configuration.
Executor	The second field. It lists the catalog executors of the provider the selected configuration belongs to, and stays disabled until you pick a Provider, showing Select a provider first. When the selected configuration was built from your own OpenAPI spec, this field is replaced by Operation, which lists the operations of that spec — see Connecting your own API.
Name	Auto-filled with the executor’s category after selection, but editable.

After selecting an executor, additional configuration fields appear based on the executor’s schema (e.g., data mapping parameters).

Available executors include:

Executor	Description
Create Account	Creates a new account in Midaz.
Create Transaction	Creates a new transaction in Midaz.
Get Account	Retrieves account details from Midaz.
Get Account Balance	Retrieves the balance for a specific account.
List Validations	Lists transaction validations from Tracer.
Validate Transaction	Validates a transaction through Tracer’s risk rules.

Executors are loaded from the Flowker catalog and may vary with OPENAPI_NATIVE_PROVIDERS, fixture policy, and successful provider and specification resolution. The table is illustrative; inspect the running catalog for the executors available to your deployment.

The node’s configuration is validated both locally and remotely (via the Flowker backend) against the catalog executor’s JSON Schema before saving. If the configuration is invalid, an error message will appear in the panel.

Conditional Node

Conditional Nodes branch the workflow based on conditions evaluated at runtime.

A conditional node holds a structured condition made of cases. Each case has one or more rules and routes the execution to its own outgoing path when it matches; cases are evaluated in order, and the first matching case wins. An optional default path catches executions that match no case — so a conditional node has one outgoing connection per case, plus the default path when enabled.

When you double-click a conditional node, its configuration panel opens with the visual condition builder, where you define the cases and the rules inside each case (the value being tested, a comparison operator, and the value to compare against).

Workflows saved with a legacy free-text condition expression keep the original true/false output paths. New conditionals use the condition builder.

Use descriptive case labels and node names (e.g., “High Value Check”) to keep the workflow readable.

Action Node

Action Nodes perform a workflow-level action without calling an external service. The available action type is set_output, which sets the execution’s final output — useful as the terminal step of a workflow, especially with synchronous webhook responses.

Output values support ${...} references resolved against the workflow context (for example, ${workflow.<field>} for the trigger payload, or ${execution.id}). For workflows triggered by a synchronous webhook, a set_output node can also carry a responseStatusCode (integer, 200–599) to override the HTTP status of the sync response.

Configuring nodes

---

To configure any node, double-click it on the canvas. A configuration panel slides in from the right side.

Each node type has its own panel layout:

• Trigger — Name field + trigger type dropdown + trigger-specific schema fields.
• Executor Call — Provider dropdown + Executor dropdown + auto-filled name + executor-specific schema fields.
• Conditional — Name field + the visual condition builder (cases and rules).
• Action — Name field + the set_output output configuration.

After filling in the configuration, click Save & Close to apply the changes and return to the canvas.

Connections

---

Connections define the order in which nodes execute. Each connection is a directed edge from one node’s output to another node’s input.

• A node can have multiple outgoing connections (e.g., conditional nodes have one per case, plus the default path when enabled).
• A node can receive input from multiple sources.
• Circular connections (loops) are not supported.

Keep your workflows readable by arranging nodes from left to right or top to bottom. Use descriptive node names to make it clear what each step does.