Workflow Block

What It Does

Drop a Workflow block when you want to call a child workflow as part of a larger flow. The block runs the child inline, waits for it to finish, and then continues with the parent.

Which version of the child runs depends on how the parent is running:

Deployed runs (API, schedule, webhook, chat, or any other execution of a deployed version) run the child's deployed version. If the child has never been deployed, the block fails with Child workflow is not deployed. Please deploy the workflow before invoking it.
Manual runs from the editor run the child's current draft, so you can test a parent and its children together before deploying either.

The child must belong to the same workspace as the parent. It must also have exactly one enabled Start or Input trigger. A child that can only be started by an external event (a webhook or schedule, for example) cannot be called inline.

Configure It

Select Workflow from the dropdown (self-references are blocked to prevent loops).
Inputs: If the child workflow's Start block defines an Input Format, you'll see each field and can connect parent variables. The mapped values are what the child receives.

Workflow block with input mapping example

Outputs: After the child finishes, the block exposes:
- result – the child workflow's final response
- success – true when the child finished (a failed child raises an error instead, see below)
- childWorkflowName – the name of the child workflow (string)
- childWorkflowId – the ID of the child workflow (string)
- childWorkflowSnapshotId – the ID of the snapshot the child ran from (string)
- error – message when the run fails. Only present on the block's error path

Deployment Status Badge

The Workflow block shows a badge on the canvas when the selected child workflow needs attention:

undeployed (red) – The child workflow has never been deployed. Deployed runs of the parent fail until you deploy it.
redeploy (amber) – The child workflow has changed since its last deployment. Deployed runs of the parent keep using the older deployed version until you redeploy.

No badge is shown when the child is deployed and current. Click the badge to deploy or redeploy the child from the canvas. This requires admin permission on the workspace, and the tooltip says so when you lack it.

Deployed runs of the parent execute the child's most recent deployed version, not its editor draft. Redeploy the child after changing it, or the parent keeps calling the old logic. Manual runs from the editor use the child's draft and are not affected.

Execution Notes

Child workflows run in the same workspace context, so environment variables and tools carry over. A child from another workspace cannot be selected or executed.
The block uses deployment versioning: API, schedule, webhook, and chat executions of a deployed parent call the child's deployed snapshot. Redeploy the child when you change it.
If the child fails, the block raises an error unless you handle it downstream. The message names the child and, for nested chains, lists the path: Workflow chain: Parent → Child → Grandchild | <root error>.
Live block events from child workflows stream to the editor and the API for up to 3 levels of nesting. Deeper children still run, but their per-block events are not streamed.

Keep child workflows focused. Small, reusable flows make it easier to combine them without creating deep nesting.

Common Questions

No. The workflow selector blocks self-references to prevent infinite loops. Additionally, SteelEngine tracks the call chain across nested executions using an internal header and enforces a maximum call chain depth of 25 hops. If the limit is exceeded, the execution is rejected with a 409 error.

The maximum call chain depth is 25. This means workflow A can call B, which calls C, and so on up to 25 levels deep. This limit applies across all chained calls, not just direct parent-child relationships.

The child workflow inherits the execution context of the parent. If the parent is running in a deployed context (API, schedule, webhook, chat), the child also uses its deployed version. An undeployed child fails the block. If the parent is running in draft mode (manual run from the editor), the child also uses its draft state. This lets you test nested workflows end-to-end before deploying.

Use the Inputs field on the Workflow block. If the child workflow's Start block defines an Input Format, each field appears in the block configuration and you can map parent variables to them. The mapped values are available as start.input in the child workflow.

The block returns a success boolean, the child workflow's result (its final response output), the child workflow's name, ID, and snapshot ID. If the run failed, the block raises an error. When an error path is connected, that path receives an error message plus the child's name. You can reference these outputs from downstream blocks using the tag syntax.

The Workflow block raises an error that propagates to the parent workflow. If you need to handle failures gracefully, connect an error path from the Workflow block to a downstream block that processes the error.