> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kapso.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Call workflow node

> Execute another workflow and return to continue execution

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`)

## Workflow library example

Use workflow slugs in local workflow source. `kapso push` resolves the slug to the Platform API `workflow_id`.

```javascript theme={null}
workflow.addNode("run_support_flow", {
  type: "call",
  workflowSlug: "support-flow",
  saveErrorTo: "support_flow_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:

```json theme={null}
{
  "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**

```mermaid theme={null}
graph LR
    A[Wait for order] --> B[Call workflow<br/>Validate Order]
    B --> C[Decide<br/>Check error]
    C --> D[Send text<br/>Success]
    C --> E[Send text<br/>Fix errors]
```

**Multi-step authentication**

```mermaid theme={null}
graph LR
    A[Start] --> B[Call workflow<br/>Verify Phone]
    B --> C[Call workflow<br/>Check Account]
    C --> D[Send template<br/>Welcome]
```

**Conditional sub-processes**

```mermaid theme={null}
graph LR
    A[Decide<br/>User type] --> B[Call workflow<br/>Premium Flow]
    A --> C[Call workflow<br/>Basic Flow]
    B --> D[Send text<br/>Complete]
    C --> D
```

## Execution stack

When workflows call other workflows, the platform maintains an execution stack visible in the UI and API responses:

```json theme={null}
{
  "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.