n8n Merge Node Modes Explained: Combine, Multiplex, and Pass-Through Under Partial Input

The n8n Merge node is one of the most frequently misused nodes in the platform. It looks simple — take data from two branches and merge it — but the four modes behave very differently when inputs arrive at different times, have unequal item counts, or one branch produces nothing.

Understanding the exact semantics of each mode will save you from subtle data loss bugs that only appear under production conditions.

The Four Merge Modes

1. Combine (Merge By Fields / Position / All)

Combine mode zips two input streams together, pairing items from Input 1 with items from Input 2.

Merge by Position (most common): Item 1 from Input 1 pairs with Item 1 from Input 2, Item 2 with Item 2, and so on. If inputs have unequal lengths, the shorter one determines the output. Items from the longer input beyond the match count are dropped.

Input 1: [A, B, C]
Input 2: [X, Y]
Output:  [{A,X}, {B,Y}]   ← C is dropped

Merge by Fields: Matches items across inputs where a specified field value matches — similar to a SQL join. Non-matching items are dropped by default.

Merge by All: Creates a cartesian product — every item from Input 1 is combined with every item from Input 2.

Input 1: [A, B]
Input 2: [X, Y]
Output:  [{A,X}, {A,Y}, {B,X}, {B,Y}]

2. Multiplex

Multiplex is a cross-join with a specific ordering: for each item in Input 1, it iterates through all items of Input 2. The total output count is count(Input1) × count(Input2).

The key difference from Combine (All) is execution order — Multiplex processes Input 1 items sequentially, pairing each with the full Input 2 list before moving to the next Input 1 item. For most use cases involving API calls downstream, this ordering matters.

3. Append

Append simply concatenates the two input arrays into one output array. No pairing, no matching. All items from Input 1 come first, then all items from Input 2.

Input 1: [A, B]
Input 2: [X, Y]
Output:  [A, B, X, Y]

This is the right choice when you’re aggregating results from parallel branches that fetched different data but need to feed into the same downstream processing.

4. Pass-Through

Pass-through outputs only one of the two inputs, ignoring the other. This is most useful when you want to use a branch for a side effect (write to a database, send a notification) but continue processing with only one stream.

The Partial Input Problem

The most confusing Merge behavior happens when one input arrives before the other — or when one branch produces no output at all.

By default, the Merge node waits for data from both inputs before executing. If a branch produces zero items (for example, a filter that matches nothing), the Merge node stalls indefinitely and the execution never completes.

Symptom: Your workflow runs but never finishes. You check the execution log and see the Merge node waiting. One of its input branches completed with no items.

Fix options:

1. Add a fallback before the Merge. Use an IF node or a Code node to inject a placeholder item when a branch produces nothing. Then filter it out after the Merge.

2. Use the “Only One Input” option. In Merge settings, enable “Only One Input” so the node proceeds if only one input has data.

3. Restructure to avoid the empty-branch problem. Sometimes the cleaner solution is to restructure the workflow so the Merge is only reached when both inputs are guaranteed to have data.

Timing and Race Conditions

In n8n, workflow branches execute in parallel by default. The Merge node handles synchronization — it waits for both inputs before producing output.

But there is a timing subtlety: the Merge node only works correctly when both inputs come from the same workflow execution. If you try to merge data from a sub-workflow (called via Execute Workflow) with data from the parent workflow, the data flows look right but the Merge may not synchronize them correctly. Use the Execute Workflow node’s output directly instead.

Field Naming Conflicts

When Combine mode merges two items, fields with the same name get overwritten. Input 2 fields overwrite Input 1 fields for the same key.

Input 1 item: { "id": 1, "status": "active", "source": "db" }
Input 2 item: { "id": 1, "status": "synced", "email": "[email protected]" }
Merged:        { "id": 1, "status": "synced", "source": "db", "email": "[email protected]" }

The status field from Input 1 is overwritten. If you need both values, rename one before the Merge using a Set node.

Which Mode to Use When

A Practical Example: Enriching a Contact List

You have a list of contacts from CRM. For each contact, you want to (a) look up their LinkedIn profile and (b) check their email deliverability. These two API calls are independent and should run in parallel.

1. Split the workflow into two branches after the CRM fetch
2. Branch A: LinkedIn API lookup
3. Branch B: Email validation API
4. Merge (Combine by Field, matching on email) to reunite the enriched data
5. Continue with a single stream of fully-enriched contacts

The Merge by Fields mode ensures that even if the LinkedIn and email validation APIs return results in different orders, the records are correctly paired.

Summary

The Merge node is powerful but requires careful thought about input cardinality, field naming, and what happens when branches produce empty results. The most common production issue is a Merge node stalling because one branch produced nothing — build a defensive pattern around this from the start, and your n8n workflows will be more reliable.