Building Flows

How to build flows using steps, groups, and edges. Learn about the different step types, group execution patterns, and how data passes between steps.

Flows are built by combining steps into groups and connecting them with edges. This page covers the building blocks and how they fit together.

Steps

A step is a single operation within a flow. Each step has a kind that determines its behavior:

Step kind	What it does
start	Entry point of the flow. Receives the flow's input data.
action	Calls an action — any platform operation or external API call.
conversation	Interacts with a conversation — runs an assistant or waits for a user response.
event	Waits for an external event (webhook, polling) before continuing.
service	Calls a built-in platform utility (data transformation, date formatting, math).
end	Exit point of the flow. Returns the flow's output data.

Step configuration

Each step is configured with:

Action identifier — which action to call (for action and service steps)
Connection ID — which credentials to use for authentication (optional, for integration actions)
Input — the data to pass to the step. Input values can be static or reference outputs from previous steps using expressions.
Output options — branching configuration that defines where execution goes next based on the step's result

Step settings

Setting	Description
Timeout	Maximum time the step can run before being terminated. Defaults to 5 minutes for action steps, 24 hours for event steps.
Continue on error	If `true`, the flow continues to the next step even if this one fails.
Retry count	Number of times to retry the step on failure before giving up.

Groups

Groups are containers that organize steps into execution patterns.

Sequential groups

Steps execute in order, one at a time. The output of each step is available to subsequent steps. This is the most common group type.

Step A → Step B → Step C

Parallel groups

Steps execute concurrently. You can configure:

Max concurrency — how many steps run simultaneously
Fail-fast — whether to stop all parallel steps if one fails

        ┌→ Step A ─┐
Start ──┼→ Step B ──┼→ Continue
        └→ Step C ─┘

Loop groups

Steps repeat based on a configured pattern:

Loop type	Behavior
n-times	Repeat a fixed number of times
for-each	Iterate over a list, running the group once per item
until	Repeat until a condition is met

Loop groups receive the current iteration index and item (for for-each loops) as input.

Edges

Edges are the connections between steps. They define execution order and data flow.

Each step has output options that determine which edges are followed:

Default edge

The standard success path. When a step completes successfully and no custom conditions match, execution follows the default edge.

Error edge

Followed when a step fails (and continueOnError is true). Error edges allow you to add error handling logic — logging, retries, fallback behavior, or user notifications.

Custom edges

Followed when specific conditions match on the step's output. Custom edges enable branching logic:

If the LLM classified the user's intent as "billing" → follow the billing edge
If the API response status is 404 → follow the not-found edge
If the data value exceeds a threshold → follow the escalation edge

Steps pass data to each other through a context that accumulates as the flow runs. Each step's output is stored under its step ID, and subsequent steps can reference it in their input configuration.

For example, if Step A returns { "count": 42 }, Step B can reference it as the output of Step A in its input mapping.

Input values support expressions that can:

Reference outputs from any previous step
Access the flow's initial input parameters
Access the flow's configuration parameters (defaults from the params schema)

Schemas

Flows define three schemas:

Schema	Purpose
inputSchema	Defines the data the flow expects when triggered. Callers must provide data matching this schema.
outputSchema	Defines the data the flow returns on completion.
paramsSchema	Defines configuration values with defaults. These are set at design time and available to all steps.

Flow Execution — how the engine runs flows
Flow Triggers — how flows are started
Actions — the operations that steps call