
n8n Merge Node: Join Workflow Data Without Losing Items
n8n Merge Node: Join Workflow Data Without Losing Items
The n8n Merge node is the place where separate workflow branches become one usable stream again. Use it when one branch has the core item and another branch has context, enrichment, status, or lookup data that must travel with it.
The mistake is treating Merge as a generic join box. It has several modes, and the wrong mode can drop unpaired items, duplicate rows, or overwrite fields you still needed. Decide whether you are appending, matching, enriching, joining by position, or choosing a branch before you wire it into a production workflow.
Quick answer: what does the Merge node do?
The Merge node combines data from multiple streams after all connected inputs are available. In current n8n versions it can append inputs, combine two inputs by matching fields or item position, output all possible combinations, run a SQL-style query, or choose which branch to keep.
For business workflows, the most useful pattern is usually Combine by Matching Fields. That is how you take a lead from one branch, enrichment data from another branch, and join them by a stable key such as email, customer ID, order ID, ticket ID, or invoice number.

Pick the mode before you build the branch
Append is for stacking items from inputs one after another. It keeps the streams separate at the item level, which is useful when two branches produce the same kind of record and you want one combined list.
Combine by Matching Fields is for joining records that describe the same thing. This is the mode to reach for when Input 1 has orders and Input 2 has customer records, or when Input 1 has leads and Input 2 has enrichment results.
Combine by Position is for pairing items by index. The first item from Input 1 joins to the first item from Input 2. This is fragile when either branch can filter, sort, retry, or return a different item count.
All Possible Combinations is for creating every pair between inputs. It is powerful, but it can explode item counts quickly. Use it deliberately, not as a shortcut for matching fields.
Use stable keys for matching fields
The safest Merge workflows match on a key that is stable, normalized, and present in both inputs. Email, customer ID, order ID, ticket ID, invoice ID, and domain can all work. Names, company names, and free-text labels are weaker because spelling and casing drift.
- Normalize emails to lowercase before the Merge node.
- Trim whitespace and map empty values to a visible fallback before matching.
- Prefer IDs from the source system when both branches can carry them.
- Log unmatched items instead of letting them disappear from the workflow.
Know what happens to non-matches
n8n lets you choose how Combine by Matching Fields handles output. Keep Matches behaves like an inner join. Keep Everything behaves like an outer join. Enrich Input 1 keeps all data from Input 1 and adds matching data from Input 2, similar to a left join. Enrich Input 2 does the reverse.
For lead, order, and support workflows, Enrich Input 1 is often the production default. It keeps the triggering business item even when enrichment is missing, then lets you route incomplete items to review.
Watch field clashes
When both inputs contain the same field name, one value can override another. n8n exposes clash handling options, including prioritizing an input or adding input numbers to field names. If both branches carry fields such as status, language, name, or source, decide which value should win before the workflow goes live.
A practical pattern is to rename important fields before the merge. For example, use crm_status and enrichment_status instead of two generic status fields. That makes later routing and debugging much easier.
A reliable enrichment workflow
Start with the trigger item as Input 1: a lead, order, form submission, ticket, or invoice. Send a copy of the item to enrichment, lookup, validation, or scoring as Input 2. Normalize the key in both branches, then Merge by Matching Fields.
- Input 1: the original item that must not be lost.
- Input 2: enrichment, lookup, dedupe result, score, or external system record.
- Mode: Combine by Matching Fields.
- Output type: Enrich Input 1 when the original item must continue even without a match.
- Next step: route matched, unmatched, and low-confidence items separately.
Common mistakes
- Using Position mode after a branch that can filter or sort items.
- Matching on display names instead of stable IDs or normalized email addresses.
- Ignoring unpaired items when the workflow needs a review path.
- Letting generic fields overwrite each other without clash handling.
- Using All Possible Combinations on large inputs without checking item counts first.
Where Synta helps
Synta is useful when the join rule is easy to describe but annoying to implement safely. Tell it the two inputs, the stable matching key, which side must be preserved, how to handle non-matches, and which fields should win when values clash.
That gives the generated n8n workflow a reviewable shape: normalize, merge, route unmatched items, then continue with alerts, CRM updates, spreadsheet rows, or support tasks.
Try the Synta MCP workflow builder
If you are building a Merge workflow in n8n, use the tracked Synta MCP path here: open Synta MCP. Describe both inputs, the matching key, the output type, clash handling, and the fallback path for unmatched items.
FAQ
When should I use Append mode?
Use Append when multiple branches produce the same kind of item and you want one combined list. Do not use it when you need to join fields from records that describe the same customer, order, lead, or ticket.
When should I use Matching Fields?
Use Matching Fields when both inputs share a stable key and you need one output item that carries data from both sides.
Is Position mode safe?
Position mode is safe only when both inputs are guaranteed to return the same items in the same order. If one branch can filter, sort, paginate, or fail, use a stable matching field instead.
How do I keep unmatched items?
Choose an output type that keeps the side you care about, such as Enrich Input 1, or use Keep Everything when you need outer-join behavior. Then route incomplete records to review instead of hiding them.