How to Call Another Workflow in n8n Easily 2026

Every n8n instance starts at an Overview screen listing the workflows, credentials, and data tables you have access to, along with summary stats like production executions and failure rate across the top. A fresh or lightly used instance might show just one workflow in the list — that's normal, and it's where you'll click in to build or edit the parent workflow that's going to call another one.

Inside a workflow, the canvas is where nodes connect left to right. A simple setup starts with a manual trigger — the "When clicking 'Execute workflow'" node — so you can run the parent workflow on demand while you're building it, before wiring it up to a real trigger like a webhook or schedule later.

Connect an Execute Workflow node to your trigger. On the canvas it shows up with its own icon and a "Workflow:" label underneath where the target gets selected — until that's set, the node displays a small warning triangle, which is exactly the state you'll see the first time you drop it in. That warning isn't a bug; it's n8n telling you the node isn't fully configured yet, since it doesn't know which workflow to call.

Click into the Execute Workflow node to open its parameters and select which existing workflow it should run — this is where your child workflow gets chosen from whatever's listed on your Overview screen. Give both the parent and the child workflow clear, descriptive names before you get very far, since "My workflow 17" and similar defaults become impossible to tell apart once you're jumping between several of them.

A child workflow often needs specific data to do anything useful, not just a bare trigger signal. In the Execute Workflow node's parameters, you can map fields from upstream nodes in the parent workflow into the data the child workflow receives, similar to how any other node passes its output forward. Keep the payload to what the child actually needs rather than forwarding everything upstream produced, since a lean payload is easier to debug when something downstream breaks.

Execute Workflow supports running the child workflow synchronously, where the parent pauses and receives data back once the child finishes, or firing it off and continuing immediately without waiting. Pick synchronous if downstream nodes in the parent depend on something the child workflow calculates or fetches; pick fire-and-forget for side tasks — like logging or a notification — that shouldn't hold up the rest of the parent's execution.

Use the manual trigger to fire the parent workflow and watch the execution path light up node by node. If the Execute Workflow node still shows an error after you've selected a target, double back into its parameters — a missing required field on the child workflow's own trigger is a common cause, since the child needs to accept whatever the parent is sending it.