Skip to main content

​
Flow Steps

A flow is a graph of steps. A trigger starts a run; the runner then works through the graph, resolving each step’s payload against the data collected so far and storing the step’s result under its step ID.
Steps do not run in sequence. The runner is a concurrent graph executor. Every step with no incoming edge starts at once, and a step starts as soon as all of its predecessors have finished — so independent branches run in parallel. This is also why one failure stops everything: the first error cancels the run, and any step still in flight is abandoned.

​
The step types

Several more node types exist and are dispatched by the runner but have no page of their own yet: Error (ends the run with a status code and message), Schedule (schedules another flow to run later), Task, Verify Challenge, Quiva Endpoint and Static. Triggers are documented separately — see Triggers.

​
What a step can read

Before a step runs, its payload is resolved: every string beginning with $. is replaced by the value that JSONPath selects. The data it selects from has these top-level keys and nothing else:
There is no ${…} syntax, no secrets key, and no filter or pipe grammar. | inside a string is a join: "Order |$.GET_ORDER.data.id| received" builds one string out of literal text and resolved values. That is the whole of it.
A result is stored flat under the step’s ID. There is no .output or .result wrapper — although an assistant’s own reply happens to live at $.STEP_ID.result, because that is a field of the response it returns.

​
Response Map

Most step types can reshape their own result before it is stored, using a Response Map — a JSONPath mapping resolved against the result the step produced:
The step then stores exactly that, so downstream steps read $.MY_STEP.id rather than digging through the original shape. Leave it empty and the result is stored unchanged. It is offered, and applied, on HTTP Request, Integration, Function, Nested flow, Rules, Task, Verify Challenge and Quiva Endpoint steps. A Condition step stores no result at all, so it has none.

​
What runs next

A Condition step’s outcome names the step IDs to run. Everything else follows from that:
  • An outcome may name one step, or several — several start at the same time.
  • Two reserved outcomes end the run: RESOLVE_SUCCESS finishes it successfully, RESOLVE_ERROR fails it.
  • An outcome naming a step that is not in the flow fails the run with next step not found.
  • An edge drawn from a Condition to a step that no outcome names is decoration. Edges are used only to work out when a step’s predecessors are all done; a branch the condition did not choose is skipped.
For every other step type, the edges are the routing: when a step finishes, each step it points at runs once all of its predecessors have finished.
A Condition step stores no result. $.my_condition holds nothing, because the runner returns before writing the result for that node type.

​
When a step fails

There is no per-step error branch. The first step to error records the failure, marks the run error and cancels it — no downstream step runs, and the failed step leaves no result for anything to inspect. Two settings soften this, both under Advanced Settings on the steps that support them: To end a run deliberately, use a Condition outcome of RESOLVE_ERROR, or an Error step, which sets a status code and message.

​
Step IDs

A step ID must start with a letter or underscore and may then contain letters, digits, underscores and colons. IDs must be unique within a flow, and four are reserved and cannot be used: trigger, static, RESOLVE_SUCCESS and RESOLVE_ERROR. Every step must have a payload, even an empty one. Function and nested-flow steps must additionally name a subject.

​
Draft and published

Editing a flow changes its draft. Save keeps your work; Publish is what makes the change take effect for live runs. Testing in the editor runs the draft, so a flow that behaves correctly under test can still be running its old published version in production until you publish.

​
Next Steps

Triggers

What can start a run

Variable Mapping

JSONPath reference for every step payload

Condition Step

How routing is actually decided

Built-in Functions

The function catalogue