The cost of copy-paste automation
A lead comes in on WhatsApp. Your workflow enriches it, scores it, writes it to Supabase, and fires a Telegram alert. A sale lands on Gumroad. Your workflow enriches it, scores it, writes it to Supabase, and fires a Telegram alert. A support ticket opens on email. Your workflow enriches it, scores it, writes it to Supabase, and fires a Telegram alert.
Three workflows, three copies of the same four steps. That is the moment you know you have outgrown a single workflow: when a fix has to land in more than one place. The alert format changes, the Supabase schema gains a column, the enrichment API key rotates. Now you are performing the same edit three times, and the fourth time will be the one where you miss it and ship stale behavior to a live channel.
The fix is not a bigger workflow. It is fewer, smaller workflows that call each other. n8n does this with the Execute Sub-workflow node (and its trigger, Execute Sub-workflow Trigger, titled "When Executed by Another Workflow" on the canvas).
How data flows in and out
The model is a straight function call wrapped in a workflow:
- Input. The Execute Sub-workflow node in Workflow A passes its data to the Execute Sub-workflow Trigger node at the top of Workflow B.
- Body. Workflow B runs its nodes as normal — enrich, score, write, alert.
- Output. The last node of Workflow B sends its result back to the Execute Sub-workflow node in Workflow A, which continues the parent flow.
Note the asymmetry: the sub-workflow's trigger node is the entry point, but the last node on the active branch is the exit. That is the detail most debugging sessions come back to.
Match the output branch, or it vanishes
n8n returns the output of the last node that produced data. If your sub-workflow branches — one path for "hot" leads, another for "support", a third for "everything else" — the parent does not get a merged result. It gets the output of whichever path ran last, and the others are empty. Put a Code node at the end that merges the branches explicitly, then let the sub-workflow end there:
// Merge branches, then end
return [
...$json.hot,
...$json.support,
...$json.other
];return [{ json: { scored: $json.scored, alerted: $json.alerted, status: $json.status } }];How to build one (the shared alert pattern)
Start with the piece you are tired of pasting. In the templates on this site that is the Telegram alert plus the Supabase write — it appears in the Gumroad sale flow, the lead enrichment flow, and several others. Extract it into a sub-workflow called shared-notify-and-store.
{
"name": "shared-notify-and-store",
"nodes": [
{
"type": "n8n-nodes-base.executeWorkflowTrigger",
"name": "When Executed by Another Workflow",
"parameters": {
"inputDataMode": "passInputData",
"options": {}
}
},
{ "type": "n8n-nodes-base.supabase", "name": "Write Lead", "...": "..." },
{ "type": "n8n-nodes-base.telegram", "name": "Alert", "...": "..." },
{ "type": "n8n-nodes-base.code", "name": "Summarize" }
]
}The sub-workflow's trigger node has three input modes. Pick deliberately:
- Pass input data (passInputData). Forward the parent's items unchanged. Use when the sub-workflow speaks the same shape as the parent.
- Pass individual variables. Map named parameters from the parent. Use when the sub-workflow needs only a few fields — it keeps the contract explicit.
- Run once for all items. Collapse the parent's batch into a single call. Use when the sub-workflow does a batch write or a single summary alert.
The parent then reads one node instead of four. When the alert format changes, you edit the sub-workflow once.
Error handling: the silent failure mode
Here is the one thing that breaks sub-workflows in production and then looks fine in the editor: if the sub-workflow errors, the parent cannot trigger it at all. You do not get a partial result and a flag you can branch on. You get a hard stop, and if your parent has no error handler attached to that node, the whole run dies.
Check before and after
Before you ship, set the parent's node options to On Error → Continue or attach an Error Trigger branch. After you ship, check the result for an explicit success flag rather than assuming output arrived:
// Parent: after Execute Sub-workflow
IF $json.success === false → retry or log
IF $json.success === true → continuesuccess boolean, even on its failure path, so the parent never has to guess from "did output arrive".
Debug path: open the Execute Sub-workflow node and select View sub-execution. That link takes you into the child run with its own log, so you do not have to guess what data actually crossed the boundary.
When the sub-workflow swallows the error
A sub-workflow with no error handling fails silently from the parent's perspective: the parent sees "workflow did not finish" and has no payload to act on. Wrap the body of the sub-workflow in a Try / Catch structure, and on the Catch branch write the error to a log table and return { success: false, error: $json.error, input: $json.original }. The parent then has something to branch on instead of a dead end.
When to stop using sub-workflows
Sub-workflows add latency and an extra execution log. They are the right call when the same logic appears in three or more parents, or when two teams own different edges of the same pipeline. They are the wrong call for a one-off chain that only one workflow ever touches — wrap a real, repeated pattern, not an imagined future one.
Also avoid making a sub-workflow that waits on an external callback (a Slack "send and await", for example). The parent gets the state of the node that preceded the wait, not the final result. Keep async handoffs in the parent; keep data transforms in the sub-workflow.
Where this ships today
The shared alert and store pattern above is bundled as a ready-to-import sub-workflow on the store. Import it, point the credential slots at your own Telegram bot and Supabase project, and call it from your next parent workflow. Fix the format once, then forget it.