Using Subworkflow Nodes

Call other workflows from within your workflow using subworkflow nodes.

Overview

A Subworkflow node invokes another workflow in your workspace as a single step. The calling workflow passes in input variables, and (in sync mode) receives the subworkflow's result as that step's output.

Subworkflows let you treat reusable logic as a building block. Common patterns - looking up a customer, posting to a notification fan-out, normalising an address - can live in one workflow and be reused from many. That keeps each workflow focused and avoids duplicating the same node graph in several places.

Before You Start

The target workflow must already exist in your workspace.
You should know which fields the target workflow expects from {{ input }} and which fields it returns.

Configuration

Drop a Subworkflow node onto the canvas.
Select the workflow to call from the dropdown.
Choose the execution mode:
- Sync - waits for the subworkflow to finish and captures its result.
- Async - starts the subworkflow and continues without waiting.
Map input variables. Each entry pairs a key the subworkflow expects with a template expression from the current workflow.

Input Mapping

Mappings are key/value pairs. The key is the field the subworkflow reads from {{ input }}; the value is a template expression from the calling workflow:

orderId - {{ step1.id }}
customerEmail - {{ step1.customer.email }}

Configuration Reference

Workflow - the target workflow to call.
Mode - Sync or Async.
Inputs - key/value list mapping subworkflow input names to template expressions.
Max nesting depth - capped at 10 levels to prevent runaway recursion.

Usage Examples

Shared notification fan-out - several order workflows call a notify-team subworkflow that sends Slack, email, and Monday.com updates in one place.
Customer lookup - a resolve-customer subworkflow takes an email and returns enriched profile fields. Any workflow that touches customers can call it instead of repeating the logic.

Tips

Keep subworkflows small and single-purpose. A subworkflow that does three different jobs is hard to reuse safely.
Document the expected inputs and outputs in the subworkflow's description so callers know the contract.
Use async mode for fire-and-forget side effects (notifications, audit logging) and sync mode when the parent needs the result.

Common Pitfalls

Async subworkflows do not return a result to the parent. Reading their output downstream gives nothing useful.
Renaming or deleting a referenced subworkflow breaks every workflow that calls it. Update callers before removing.
Deep nesting hits the 10-level cap quickly. If you find yourself stacking subworkflows, flatten the design.

Learn More

Subworkflow node documentation