Skip to main content

Call Process 🔄

Invokes another workflow as a child execution and waits for it to complete.

Node type: callProcess Category: Flow Control Actor: callProcess (2 threads)

Description​

The Call Process node starts a completely separate workflow (another process definition) and waits for it to finish before continuing the current workflow. The child workflow runs as a new process instance with its own processInstanceId.

Use Call Process to:

  • Break large workflows into reusable sub-workflows
  • Compose workflows from building blocks
  • Reuse common flows (e.g., "Send Notification", "Create Customer Record") across multiple parent workflows

Call Process differs from Sub-Process: Call Process runs a separate, independently deployed workflow definition, while Sub-Process embeds the logic inline.

Properties​

PropertyTypeRequiredDescription
targetProcessIdprocessDropdownYesThe workflow to invoke

Data Passing​

The parent workflow passes its current execution variables to the child workflow as the data input. The child's output variables (the final data state when it reaches its End Event) are merged back into the parent workflow's variable scope.

Parent → Child​

All current parent variables are available in the child workflow:

Parent has: {customerId}, {orderTotal}, {items}
→ Child receives all of these as initial variables

Child → Parent​

When the child workflow completes, its final variable state is merged into the parent:

Child sets: {processedOrderId}, {trackingNumber}, {invoiceUrl}
→ Parent can now access {processedOrderId}, {trackingNumber}, {invoiceUrl}

If the child sets a variable that also exists in the parent, the child's value overwrites the parent's after completion.

Connections​

ConnectionDescription
sequenceFlow (incoming)Arrives from parent workflow
successFlow (outgoing)Taken when child completes successfully
errorFlow (outgoing)Taken when child execution fails
timeoutFlow (outgoing)Taken if child exceeds the Call Process timeout

Example: Reusable Notification Workflow​

Parent workflow:

[Process Order] → [Call Process: Send Order Notifications] → [Update Inventory]

Child workflow (Send Order Notifications):

[Start] → [Email: Order Confirmation to {customerEmail}]
        → [SMS: Shipping update to {customerPhone}]
        → [Slack: Alert to operations team]
        → [End]

The parent passes {customerEmail}, {customerPhone}, {orderId} to the child. The child sends all notifications independently. When complete, the parent continues to update inventory.

Child Execution Visibility​

The child process instance is a fully independent execution in the system:

  • It appears in the Executions list with its own processInstanceId
  • Its parent_instance_id field references the parent
  • All child node instances are viewable in the execution detail
  • The parent instance is in "waiting" state while the child runs

Error Handling​

If the child workflow fails (any unhandled node failure):

  • The Call Process node takes the errorFlow if connected
  • The parent's {_error} variable contains the child's error message
  • The child process instance is marked Failed

If no errorFlow is connected, the parent workflow also fails.

Timeout Configuration​

Set a timeout on the Call Process node to avoid waiting indefinitely for a stuck child:

{
  "timeout": {
    "duration": 5,
    "durationUom": "MINUTES",
    "action": "FAIL"
  }
}

Best Practices​

  • Use Call Process for reusable workflow segments used in 2+ parent workflows
  • Name child workflows clearly (e.g., "Send Order Notifications", "Validate Customer Identity") — they appear in the designer dropdown
  • Always connect errorFlow to handle child failures gracefully
  • Set a timeout — if the child workflow has an Input Node waiting for human input, the parent will wait indefinitely without one
  • For fire-and-forget (non-waiting) sub-process invocation, use a Service Task calling the POST /process/exec API instead