Advanced Guide: Passing Data in n8n Sub-workflows

As your automation infrastructure grows, you will inevitably build complex workflows with dozens of nodes. Placing everything on a single n8n canvas leads to several issues: slow UI rendering, difficulty in debugging individual blocks, and zero reusability of logic.

The solution is Sub-workflows. Similar to writing functions in traditional programming languages, sub-workflows allow you to isolate specific business logic (like standardizing email data, formatting PDFs, or logging errors) and trigger them from multiple "parent" workflows.

In this advanced guide, we will cover how to design sub-workflows, pass parameters back and forth, and structure robust error handling.

Understanding the Key Nodes

To establish communication between workflows, n8n utilizes two core nodes:

1. Execute Workflow Node: Used inside the parent workflow to call a child workflow using its target ID.
2. Execute Workflow Trigger: Used as the starting node of the child workflow. It receives variables passed from the parent.

Step 1: Designing the Child Sub-workflow

To begin, we need to create the child workflow that performs a specific task. For example, let's create a sub-workflow that takes a customer name and temperature value, formats a message, and logs it.

1. Create a new blank workflow in n8n.

2. Set the trigger node to **Execute Workflow Trigger**. This node has no configurations because it automatically inherits data from whatever parent node executes it.

3. Add a **Code Node** (JavaScript) to calculate formatting, with this sample snippet:

// Child Workflow Code Node
const inputData = $json; // Inherits from trigger

const customerName = inputData.name || 'Valued Client';
const rawTemp = inputData.temp || 0;
const status = rawTemp > 38 ? 'High Fever' : 'Normal';

return {
  json: {
    message: `Patient ${customerName} has a ${status} status.`,
    timestamp: new Date().toISOString()
  }
};

4. Save the workflow and note the ID in the browser URL bar (e.g., https://n8n.yourdomain.com/workflow/12, where 12 is the workflow ID).

Step 2: Configuring the Parent Workflow

Now, let's configure the main workflow to send variables to the child.

1. Open your parent workflow canvas.

2. Add the **Execute Workflow** node.

3. In the node settings panel:

• Set **Source** to Database.
• Select your child workflow by name or paste its numerical ID (e.g., 12) in the **Workflow** selector field.

4. To pass parameters to the child, place a **Set Node** directly before the Execute Workflow node. Define the variables you want to pass (e.g., name and temp).

// Parent Set Node config
Name: John Doe
Temp: 39.2

When you trigger the parent workflow, the Set node data flows into the Execute Workflow node, which packages the active JSON payload and passes it directly to the child's Execute Workflow Trigger.

Step 3: Handling Returned Outputs

By default, the **Execute Workflow** node in the parent acts synchronously. It pauses execution, waits for the child workflow to complete all its steps, and returns the output JSON of the child's final active node back to the parent.

In our example, once child workflow 12 completes, the parent Execute Workflow node output will look like this:

[
  {
    "message": "Patient John Doe has a High Fever status.",
    "timestamp": "2026-06-06T20:30:00.000Z"
  }
]

You can now use this output string in subsequent nodes in the parent workflow (e.g., to send an SMS or update a sheet).

Step 4: Error Handling in Sub-workflows

If a node fails inside a child workflow, the entire execution terminates, and the parent Execute Workflow node returns an error. To prevent this in production, implement this routing pattern:

1. Open the child workflow.
2. On critical nodes (like external database connections), click the settings cog and set **On Error** to Continue Workflow or route to a fallback branch.
3. Alternatively, write error notifications to a central Slack channel inside the child workflow so the parent continues processing other records without crashing.

Conclusion

Modularizing your automation logic using sub-workflows keeps your n8n workflows clean, reusable, and maintainable. By treating child workflows as modular functions, you can scale your automation tasks across departments without cluttering your editing canvas.