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 waits for the child to finish before continuing. An editor run uses the child's draft; a deployed parent run uses the child's active deployment.

Configure It

  1. Pick a workflow from the dropdown (self-references are blocked to prevent loops).
  2. Map inputs: The child workflow's Start fields appear in Input Mapping. Map parent values to them; the child reads each named field as <start.fieldName>.
  1. Outputs: After the child finishes, the block exposes:
    • result – the child workflow's final response
    • success – whether it ran without errors
    • error – message when the run fails
    • childWorkflowName – 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 has no active deployment. Deploy it before invoking it from a deployed parent; editor runs can use its draft.
  • 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.

Before deploying the parent, deploy the child. Redeploy the child after editing it for deployed parent runs to pick up those changes.

Execution Notes

  • Child workflows run in the same workspace context, so environment variables and tools carry over.
  • Child workflows inherit the parent's execution context: editor runs use the child draft; deployed runs use its active snapshot.
  • 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, Studio 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 Input Mapping on the Workflow block. The child workflow's Start fields appear there, and you map parent values to them. The child reads each named field as <start.fieldName>.
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.
WebhookEvaluator