Copy-paste is a loan you repay every time something changes

By now you can read a workflow, branch it with IF and Switch, catch its failures with an Error workflow, and reshape its data with Edit Fields. You also have more and more workflows, and they are starting to look alike.

Then one day you open your own n8n home page and see it. Those four steps for “send a Slack notification” — an IF on severity, a Set for the title, a Slack node to send the message, a row appended to Sheets — are sitting inside five different workflows, identical in all five.

That is where copy-paste development always ends up. The fix is to pull those four steps out into a small standalone workflow — a sub-workflow — and have the other workflows call it with an Execute Workflow node. From then on, changing the shared logic means changing that one workflow, and every caller picks up the new version automatically.

A sub-workflow is not a special kind of workflow

There is no sub-workflow node type and no add-on to install. A sub-workflow is an ordinary workflow, just one designed to be called by others. The whole mechanism rests on two nodes playing two roles.

Put together, that is a function call with the four familiar moves: the caller passes arguments, the sub-workflow runs on them, the last node's items come back as the return value, and the caller treats that return value as the Execute Workflow node's output and carries on downstream.

sequenceDiagram
  participant U as Node before the call
  participant C as Execute Sub-workflow
  participant T as Execute Sub-workflow Trigger
  participant L as Last node of the sub-workflow
  U->>C: items arrive from upstream
  C->>T: hands those items over as arguments
  T->>L: the sub-workflow runs its own nodes
  L-->>C: the last node's items come back as the return value
  C->>C: that becomes this node's output

Split too eagerly and you trade one mess for another

Not every piece of logic is worth splitting out. Do it too readily and your workspace fills with fragment workflows, which makes things harder to manage rather than easier. Run the question through this before you reach for a new workflow.

flowchart TD
  A["A run of logic you are
thinking of splitting out"] --> B{"Does the same logic appear
in three or more workflows?"}
  B -->|"yes"| S["Split it out"]
  B -->|"no"| C{"Is it ten or more nodes,
messy even to you?"}
  C -->|"yes"| S
  C -->|"no"| D{"Does one setting inside it
need managing in one place?"}
  D -->|"yes"| S
  D -->|"no"| E{"Does another team or colleague
need to call this logic?"}
  E -->|"yes"| S
  E -->|"no"| F["Leave it where it is"]

A shared “send a Slack alert” workflow, built once

Take one concrete case. The logic to split out is: take an event, decide the channel and the color from its severity — error, warn or info — and send it to Slack. After this, any workflow that needs to notify somebody calls this one instead of assembling Slack itself.

flowchart LR
  T["Execute Sub-workflow Trigger
input schema from a JSON example"] --> S{"Switch or IF
on the severity field"}
  S -->|"error"| E["Slack node
error channel, red"]
  S -->|"warn"| W["Slack node
warn channel"]
  S -->|"info"| I["Slack node
info channel"]

1. Step 1

   Create the workflow and name it with a prefix

   From the home page, Workflows → + Create workflow. Click the workflow name in the top right and change it to [Sub] Slack Alert. The [Sub] prefix is a convention — the naming section below covers the rest of them — and it tells you at a glance that this workflow exists to be called and never runs on its own.

2. Step 2

   Use Execute Workflow Trigger as the trigger node

   On the canvas press Tab, or click +, to open the nodes panel. Search for Execute Workflow Trigger in the trigger family and drag it in. Its role is “when somebody calls me, I start here”. Without it, another workflow's Execute Workflow node finds no entry point at all.

3. Step 3

   Set Input data mode to Define using JSON example

   Open the Execute Sub-workflow Trigger node and find the Input data mode dropdown. There are three options: Define using fields below (type each field name and type by hand), Define using JSON example (paste a sample and n8n infers the schema for you) and Accept all data (no validation — whatever arrives is taken). Choose Define using JSON example and paste this object:

   { "severity": "error", "message": "Database connection failed", "source": "backup-daily" }

   Three keys, and each one earns its place:

   Field	Example value	What the sub-workflow does with it
   severity	"error"	Chooses the branch, and therefore the channel
   message	"Database connection failed"	The body of the Slack message
   source	"backup-daily"	Says which workflow raised it, so a reader knows where to look

   The benefit is on the other side: the caller sees this schema hint in its own Execute Sub-workflow node and can assemble its data to match, which saves the back-and-forth over “what am I supposed to send you”. A team that wants the contract written down first picks Define using fields below; a team that would rather take anything and sort it out later picks Accept all data.

4. Step 4

   Add an IF node to test the severity

   Wire in an IF node with the condition {{ $json.severity }} equals error. The true branch goes to “post in the #ops-error channel with a red icon”. The false branch gets another IF for warn and info — or you can split three ways in one go with a Switch node, which is what Switch is designed for.

5. Step 5

   One Slack node per branch, with the channel following the severity

   Give each branch its own Slack → Message → Send node. The error branch's Channel is #ops-error, warn takes #ops-warn, and info takes #ops-info. Build the Text field from one shared expression in all three:

   [{{ $json.severity | upper }}] {{ $json.source }}: {{ $json.message }}

   All three channels then get the same-looking message, and you maintain that format in one place.

6. Step 6

   Let the workflow end on its own

   Let each of the three Slack nodes be the end of its branch. When a sub-workflow finishes, the last node's items are sent back to the caller as the return value automatically. Do not add a Respond to Webhook node — that one belongs to the Webhook node, not to sub-workflows. If you want to return a structure of your own instead, put a Set / Edit Fields node at the end of each branch and build it there, for example { "notified": true, "channel": "#ops-error" }.

7. Step 7

   Save, and note the workflow ID from the address bar

   Save with Ctrl + S, then look at the browser address bar. It reads something like https://n8n.woowtech.io/workflow/abc123XYZ, and that last segment is the workflow ID. If the caller's Workflow dropdown cannot find this workflow later, you can paste the ID straight in. One thing not to do here: a sub-workflow does not need its Active toggle switched on, because it never runs from a trigger of its own. It waits to be called.

8. Step 8

   Test it once from the trigger node

   Click Execute step in the top right of the Execute Workflow Trigger node. It does a trial run using the data you pasted into the JSON example as its input. Of the three Slack nodes, only the error branch should fire, because the example's severity is error. A Slack message actually arriving means the sub-workflow itself is sound.

Delete the four nodes, drop in one

The sub-workflow is built. Now open an existing workflow — “back up the database daily”, say — take out the Slack notification nodes stuffed inside it, and replace them with a single Execute Workflow node.

1. Step 1

   Open the workflow you are reworking

   Say you have a workflow that backs up the database in the small hours: a Schedule Trigger, then the backup, then an IF on the exit code, then a Slack message each for success and failure. It is that last stretch you are about to take apart.

2. Step 2

   Delete the old Slack nodes and drag in Execute Workflow

   Delete your own IF, Set and Slack nodes entirely. Search the nodes panel for Execute Workflow — the action one, not the trigger version, which is easy to grab by mistake — and wire it in after the IF node.

3. Step 3

   Set Source to Database and pick the sub-workflow

   Open the node. Source has four modes: Database (pick from the workflows already in the workspace, the usual choice), Local File (read a JSON file from the machine), Parameter (paste the whole workflow JSON into the node) and URL (point at a workflow URL). Keep the default Database and find [Sub] Slack Alert in the dropdown. If it is not there, switch to one of the other modes and point at it by hand.

4. Step 4

   Decide on Wait for Sub-workflow Completion

   This toggle decides whether the caller waits for the sub-workflow to finish and hand back a return value before carrying on. On means wait; off means carry on the moment the call goes out, which suits a pure notification where you do not care about the result. If you want to keep working with the data the sub-workflow returns, it has to be on. The official docs do not state the default; in practice a newly created Execute Sub-workflow node has it on, so check it yourself if you want to be sure.

5. Step 5

   Set Mode to Run once with all items

   Mode has two options. Run once with all items hands every upstream item to the sub-workflow at once and the sub-workflow runs a single time. Run once for each item triggers the sub-workflow separately per item, so it runs N times. For a one-at-a-time case like a notification, Run once with all items is fine.

6. Step 6

   Fill in what you pass, or reshape it first

   If the sub-workflow defined a schema on its trigger — either Define using fields below or Define using JSON example — the Execute Sub-workflow node automatically shows a Workflow Inputs table where you fill in an expression per field, plus an Attempt to convert types toggle that handles type conversion for you. If the sub-workflow is on Accept all data, that block does not appear and the upstream items go in untouched. To change the structure substantially, add a Set / Edit Fields node in front and build the three fields there:

   severity: error

   message: {{ $json.error_message }}

   source: backup-daily

   Then save and run it once by hand with Execute Workflow to verify three things in one go: the sub-workflow wakes up, Slack gets the message, and the Execute Workflow node on the caller's side shows the items that came back.

Two ways to pass parameters, and one to avoid by default

How does the Execute Workflow node decide what to hand over? There are three settings worth knowing, and the third one is the one that bites.

sequenceDiagram
  participant P as Parent workflow
  participant S as Sub-workflow
  Note over P,S: Wait for Sub-workflow Completion, on
  P->>S: call, with items
  S-->>P: returns items when it finishes
  P->>P: downstream nodes run, using what came back
  Note over P,S: Wait for Sub-workflow Completion, off
  P->>S: call, with items
  P->>P: downstream nodes run straight away
  S->>S: finishes on its own, return value goes nowhere

Six limits, a prefix convention, and a starter toolbox

Splitting logic out feels good. A handful of practical limits are worth knowing now rather than tripping over them six months from now.

Prefixes, so you can tell them apart at a glance

After a while a workspace holds dozens or hundreds of workflows, half of them parents and half of them called by others. All mixed together, you cannot find anything. Sorting by prefix is the simplest thing that works.

The workflow list page supports search, so typing [Sub] brings up every sub-workflow at once, which makes both editing and taking stock easy. WoowTech's own team has used this convention for a long time, and a new colleague gets it in a second.

A starter toolbox of four

Once the idea has landed, you can build your team a shared toolbox. Here are four sub-workflows plenty of companies actually run, for reference.

With those four built, everything else gets cleaner. Need to notify? Do not assemble Slack yourself — call [Sub] Slack Alert. Need a log? Call [Sub] Log Execution. Need to show a time to a person? Call [Sub] Format Local Date and the whole company shows one format. Need to look up a colleague? Call [Sub] Get Employee Info, and when the internal API changes URL you edit exactly one workflow.

Later the HR API address changes, the Slack channel is renamed, the timezone format is adjusted — you edit only the matching sub-workflow, and every workflow in the company picks up the new version automatically. That is what sub-workflows are really worth. The first one costs you time to build and an interface to explain to colleagues — what to send, what comes back — but every extra caller doubles the return on the set again.

Which side is broken, the caller or the callee

Two workflows means two places a fault can live, and the Executions page will not join them up for you. Work out which side you are on first.

flowchart TD
  A["The call did not do
what you expected"] --> B{"Can the Workflow dropdown
even find the sub-workflow?"}
  B -->|"no"| B1["Check it still exists on the Workflows page,
or point at it by hand with
URL, Local File or Parameter"]
  B -->|"yes"| C{"Does the run say the
sub-workflow could not be started?"}
  C -->|"yes"| C1["The first node is not an
Execute Sub-workflow Trigger.
Fix the entry point"]
  C -->|"no"| D{"Did items actually arrive
at the Execute Workflow node?"}
  D -->|"no"| D1["Nothing upstream, or the wrong Mode.
The sub-workflow was never called"]
  D -->|"yes"| E{"Did the sub-workflow
return empty items?"}
  E -->|"yes"| E1["A branch inside it ends on nothing.
Give every path a real end node"]
  E -->|"no"| F["Both sides ran. Open the two
executions and compare by time"]

Where to go from here