A workflow that starts with five nodes rarely stays at five nodes. You add a branch for the edge case, then a retry, then a formatting step for a second downstream app, and eighteen months later you’re scrolling sideways through a canvas nobody wants to open. Sub-workflows are n8n’s answer to that: instead of one enormous workflow doing everything, you split the logic into smaller workflows that call each other.
What a sub-workflow actually is
There’s no special “sub-workflow” object in n8n. Any workflow can be called by another workflow, and any workflow can call another workflow. The relationship is created by two nodes working together.
In the workflow doing the calling (the parent), you add an Execute Sub-workflow node. In the workflow being called (the child), the first node has to be an Execute Sub-workflow Trigger, labeled “When Executed by Another Workflow” on the canvas. When the parent runs, it hands data to that trigger, the child workflow runs through its own nodes, and whatever the child’s last node produces gets sent back to the Execute Sub-workflow node in the parent. From there, the parent keeps going as if that data had come from a normal node.
Setting up the child workflow
Start with the child, since the parent needs to know what it expects. Drop an Execute Sub-workflow Trigger node at the start of a new workflow and configure its input data mode. You get three choices: define the inputs as named fields with types, define them with a JSON example so n8n infers the shape, or accept all data with no defined contract at all.
Accept all data is the fastest to set up and the easiest to get wrong later, because nothing stops the parent from sending the wrong shape of data and the child silently working with garbage. Defining fields explicitly costs a few minutes up front and pays that back the first time someone (including future you) forgets what a sub-workflow needs.
Setting up the parent workflow
Back in the calling workflow, the Execute Sub-workflow node needs to know where the child lives. You can point it at a workflow in your own instance by ID, either picked from a list or typed in directly, at a local JSON file on the host machine, at a URL, or at raw JSON pasted into a parameter. Database-by-ID, picking from the list, is what you’ll use almost every time. The other three exist for cases like loading a workflow definition dynamically or keeping one in version control outside the n8n database.
If you picked the child from the list and its trigger isn’t using “Accept all data,” the node auto-populates a field for every input the child expects, ready for you to map values into. That’s the main payoff of defining inputs explicitly on the child side: the parent gets a real form instead of a blank JSON box to fill in from memory.
There’s also a Mode setting: run the sub-workflow once with all the incoming items bundled together, or run it once per item, looping through each one as a separate execution. Which you want depends entirely on what the child does. A sub-workflow that generates one summary report from a batch of rows wants all items at once. A sub-workflow that sends one notification per row wants to run once per item.
Waiting or not waiting
One option is easy to skip past and worth understanding: Wait for Sub-Workflow Completion. Turned on, the parent pauses until the child finishes and only then continues, using whatever the child returns. Turned off, the parent fires the sub-workflow and moves on immediately without waiting for a result.
Waiting is what you want almost all the time, since the parent usually needs the child’s output to keep going. Not waiting is for genuine fire-and-forget cases, logging something or kicking off a slow background job where the parent has no use for the result and shouldn’t be held up by it.
Why this is worth the extra hop
The obvious reason is readability. A parent workflow that calls “Validate Order,” “Charge Payment,” and “Send Confirmation” as three sub-workflows tells you more at a glance than the same logic flattened into thirty nodes on one canvas. But the real payoff shows up in reuse. If three different parent workflows all need to send the same formatted Slack alert, that formatting and sending logic belongs in one sub-workflow that all three call, not copy-pasted three times and drifting out of sync the first time someone edits one copy and forgets the other two.
It also makes testing more honest. A sub-workflow with a defined input contract can be triggered manually with test data and checked on its own, without needing to replay the entire parent flow to reach the part you’re actually trying to debug.
If you’ve already built a chunk of nodes inside a larger workflow and want to pull it out, you don’t have to rebuild it from scratch. Selecting the nodes and using the canvas’s option to extract them into a new workflow turns that chunk into its own sub-workflow automatically, wired up with a trigger, and swaps it into the original spot as an Execute Sub-workflow call.
One practical detail that helps when something goes wrong: executions are linked in both directions. Open a parent’s execution log and there’s a link straight to the matching sub-execution. Open the sub-execution and there’s a link back. You don’t have to guess which sub-workflow run corresponds to which parent run when you’re staring at a failure at ten at night.
Where this series goes next
Splitting workflows into smaller pieces matters more once you’re running n8n as real infrastructure rather than a handful of personal automations, and that’s exactly the territory we’re heading into next: self-hosting n8n in production, queue mode, workers, and scaling it all with Docker Compose.