Execution order v2

The Runtime executes a Workflow as an ordered tree of Steps. Root Steps form the main sequence. Container Steps add conditional, iterative, or error-handling sequences beneath them.

Defined order

At one scope level, Steps are executed in their authored order. A later Step can map data from an earlier Step. A forward reference to a later Step is invalid.

Step names are the stable reference identity within the Workflow. Visual placement is a representation of the same ordered structure; it does not create a separate execution graph.

Data dependencies and lazy values

Authored order defines which data is available, but it does not mean every returned value is fully materialized as soon as its producing Step appears.

A Stream or collection can remain deferred until a later consumer reads it. The producer Step has executed, while part of its result is still pulled on demand. Multiple or conditional consumers can cause the runtime to retain replay data so each valid consumer sees the required values.

This is why execution timing and log completion for a producer can extend into downstream work. See Lazy Evaluation and Streaming.

Branches

An If evaluates its boolean condition and runs only one branch. The unselected branch is closed and cannot produce values.

After the selected branch completes, execution continues with the next Step after the If container. Later Steps must depend only on data guaranteed by the chosen path or on a value deliberately exposed by the container contract.

Iteration

A ForEach obtains its Items source, then runs its child Steps for each current item. The active item is available only inside the loop through {loopName.Items...}.

Iterations are orchestrated in source order. The mapped Result is accumulated in that order and can remain a deferred collection for its consumer. Do not assume parallel iteration unless a specific Node or documented pattern provides it.

Error handling

A TryCatch runs Try. If no error occurs, it skips Catch; if a Step fails, it abandons the remaining Try work and enters Catch. Finally follows either path.

Without a matching active TryCatch, a Step error propagates out of the current scope and generates a Workflow-level exception. Nested handlers catch errors within their own boundary before an outer handler sees an unhandled error.

Sub-Workflows

A Sub-Workflow call is one Step in the parent order. It supplies the child Parameters, waits for the required child result, and maps child Returns back into the parent. The child has its own execution tree, logging context, and activation state while inheriting the caller's Environment.

An error not handled inside the child is surfaced to the parent call and can be handled by a parent TryCatch.

Workflows can call v1 Runtime Workflows through the Sub Workflow Node. This approach supports progressive migration to the Runtime while reusing assets built for the v1 Runtime.

Trigger boundaries

For a triggered Workflow, the receive Step establishes request, event, or schedule context before dependent Steps run. HTTP and MCP designs finish through one root-level respond Step.

The response can depend on deferred data. The runtime consumes or streams that data as required by the selected response Method before the transport finishes.

Design guidance

Keep dependencies flowing from earlier Steps to later Steps.
Put the smallest useful sequence inside a branch or loop.
Avoid references across sibling branches.
Name Steps for the action or result they own.
Materialize or replay data only when the consumer contract requires it.
Extract a stable, reusable section into a Sub-Workflow.

Review the Preview tab to inspect mapped sample values and the Problems tab to review Workflow design issues.