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. Start with a manual trigger, the "When clicking 'Execute workflow'" node, so you can run the parent on demand while building it, before wiring it up to a real trigger later.

Connect what n8n now calls the Execute Sub-workflow node to that trigger. The node was called Execute Workflow in older versions, and plenty of tutorials and forum threads still use that name, but current n8n ships it as Execute Sub-workflow with a matching Execute Sub-workflow Trigger for the child side.

On the canvas it shows its own icon and a Source field where the target gets picked; until that's set, the node displays a warning triangle. That warning isn't a bug. It's n8n telling you the node doesn't yet know which workflow to call.

Click into the node to open its parameters. Source defaults to Database, and from there you pick From list to choose an existing workflow by name, or enter its ID directly if you already know it.

This is where your child workflow gets selected from whatever's listed on your Overview screen. Give both the parent and the child 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 usually needs real data, not just a bare trigger signal. If the child starts with its own Execute Sub-workflow Trigger node, that trigger's defined input fields show up automatically in the parent's node for you to map from upstream data; without one, n8n just starts at the child's first node and hands it whatever the parent sent.

The node's Mode setting also controls how many times the child runs: Run once with all items passes every input item into a single execution, while Run once for each item runs the child separately per item. Pick the one that matches what the child is meant to do, and keep the mapped payload to what the child needs, not everything upstream produced.

The Wait for Sub-Workflow Completion option controls whether the parent pauses and receives data back once the child finishes, or continues immediately without waiting. Turn it on if downstream nodes in the parent depend on something the child calculates or fetches. Leave it off for side tasks, logging or a notification, that shouldn't hold up the rest of the parent's run.

Use the manual trigger to fire the parent and watch the execution path light up node by node. If the Execute Sub-workflow node still errors after you've picked a target, open the child workflow and check its own Execute Sub-workflow Trigger for a required input field the parent isn't sending; a mismatch there is the most common cause once the warning triangle itself is gone.