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 latest deployed version of that workflow, waits for it to finish, and then continues with the parent.
Configure It
- Pick a workflow from the dropdown (self-references are blocked to prevent loops).
- Map inputs: If the child workflow has an Input Form trigger, you'll see each field and can connect parent variables. The mapped values are what the child receives.
- Outputs: After the child finishes, the block exposes:
result– the child workflow's final responsesuccess– whether it ran without errorserror– message when the run failschildWorkflowName– the name of the child workflow (string)childWorkflowId– the ID of the child workflow (string)
Deployment Status Badge
The Workflow block displays a deployment status badge to help you track whether the child workflow is ready to execute:
- Deployed – The child workflow has been deployed and is ready to use. The block will execute the current deployed version.
- Undeployed – The child workflow has never been deployed. You must deploy it before the Workflow block can execute it.
- Redeploy – Changes have been detected in the child workflow since the last deployment. Click the badge to redeploy the child workflow with the latest changes.
The Workflow block always executes the most recent deployed version of the child workflow, not the editor version. Make sure to redeploy after making changes to ensure the block uses the latest logic.
Execution Notes
- Child workflows run in the same workspace context, so environment variables and tools carry over.
- The block uses deployment versioning: any API, schedule, webhook, manual, or chat execution calls the deployed snapshot. Redeploy the child when you change it.
- If the child fails, the block raises an error unless you handle it downstream.
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, Sim 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), the child also uses its deployed version. 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 has an Input Form trigger, 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 and ID, and an error message if the run failed. 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.
