> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](/en/flowker/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](/en/flowker/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). |

<Note>
  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.
</Note>

### 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](/en/flowker/console/providers-overview) 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](/en/flowker/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. |

<Note>
  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.
</Note>

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).

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

<Tip>
  Use descriptive case labels and node names (e.g., "High Value Check") to keep the workflow readable.
</Tip>

### 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](/en/flowker/integration-guide#synchronous-response-mode).

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.

<Tip>
  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.
</Tip>