Skip to main content
Execute another workflow as a subroutine. The parent workflow pauses while the child workflow runs, then resumes with merged variables when the child completes.

​
Configuration

  • id: Unique node identifier
  • workflow_id: ID of the workflow to call
  • workflow_name: Display name of called workflow (read-only)
  • save_error_to: Variable name to store error details if child workflow fails (optional, defaults to subworkflow_error)

​
How it works

  1. Creates child execution: Starts a new execution of the called workflow with copied context
  2. Pauses parent: Parent workflow enters waiting state until child completes
  3. Merges variables: When child finishes, its variables merge into parent’s vars
  4. Handles errors: If child fails, error details saved to configured variable
  5. Continues execution: Parent resumes from next step after child completes

​
Execution context

The child workflow receives:
  • Copy of parent’s vars (workflow variables)
  • Copy of parent’s system variables
  • Copy of parent’s context (phone_number, channel, etc)
  • Same WhatsApp conversation if applicable
Variable changes in the child automatically merge back to parent on completion.

​
Error handling

If the child workflow fails, error details are stored in the configured variable: 
{
  "error": "Workflow call cycle detected",
  "workflow_id": "abc123",
  "workflow_name": "Order Processing",
  "call_stack": ["flow1", "flow2", "flow3"]
}
Common error scenarios:
  • Cycle detection: Workflow calls itself directly or indirectly
  • Max depth exceeded: Call stack exceeds 10 levels
  • Non-executable workflow: Called workflow is not published/active
  • Insufficient credits: Not enough credits to execute child workflow

​
Safeguards

Recursion protection
  • Detects circular calls (workflow A → workflow B → workflow A)
  • Maximum call depth of 10 workflows (prevents infinite recursion)
  • Errors stored in variables instead of failing entire workflow
Execution isolation
  • Each call creates independent execution record
  • Parent and child executions visible in execution history
  • Child execution shows in parent’s execution stack

​
Usage patterns

Reusable order validation Multi-step authentication Conditional sub-processes

​
Execution stack

When workflows call other workflows, the platform maintains an execution stack visible in the UI and API responses: 
{
  "id": "parent_exec_123",
  "flow": { "name": "Main Workflow" },
  "execution_stack": [
    {
      "id": "parent_exec_123",
      "flow": { "name": "Main Workflow" },
      "status": "waiting",
      "current_step": { "identifier": "call_order_validation" }
    },
    {
      "id": "child_exec_456",
      "flow": { "name": "Order Validation" },
      "status": "running",
      "current_step": { "identifier": "check_inventory" }
    }
  ]
}
The execution stack shows the full call chain from root to currently executing workflow.

​
Best practices

Design reusable workflows: Create focused workflows that handle single responsibilities (validation, notifications, data processing). Handle errors explicitly: Always check the error variable after calling workflows that might fail. Avoid deep nesting: Keep call depth under 3-4 levels for maintainability. Share via variables: Use vars to pass data between workflows - changes in child workflows automatically merge back. Test call chains: Use test mode to verify the full execution path including all child workflows.