FlowKit

The Merge node in n8n: combining data from multiple branches without breaking anything

Published 22 July 2026 · 6 min read

An n8n workflow that stays linear from trigger to last step is rare: as soon as an IF, a Switch, or a parallel API call enters the picture, data ends up spread across several branches — and needs recombining before the workflow continues. That's exactly the job of the Merge node, one of the most-used core nodes and yet one of the most misunderstood, because its four modes don't behave anything alike. Picking the wrong mode doesn't always throw a visible error: sometimes the workflow runs fine while silently scrambling or dropping data. This guide covers the four modes, their pitfalls, and a practical use case pulled straight from AI automation workflows.

Why the Merge node shows up in almost every AI workflow

The need to recombine branches shows up whenever a workflow enriches a piece of data without replacing it. A typical example: an email goes through an AI classification node (as in our guide to AI email triage) that returns a category and a summary — but the rest of the workflow also needs the original email body, sender, and received date. You have two options: either the LLM prompt returns every original field on top of its classification (fragile, expensive in tokens, and the model might alter a field it was only supposed to copy), or you let the LLM return only what it produced, then recombine it afterward with the original data using the Merge node. The second approach is almost always the right one: it cleanly separates what the model must produce from what it must carry along.

The Merge node's four modes

Append: stacking with no pairing

Append concatenates items from both inputs, in order — all of input 1's items first, then all of input 2's. No pairing happens between items: if you're trying to attach a piece of data from one branch to its counterpart in the other, this isn't the right mode. Append fits the opposite situation instead: gathering independent results from several branches into a single stream, for example the outputs of several Switch branches that aren't meant to be compared to each other, ahead of a shared step (writing to the same table, for instance).

Combine: the most-used mode, with three variants

Combine merges items pairwise instead of stacking them, based on one of three "Combine By" settings:

  • Matching Fields — the most reliable mode for enrichment: you specify a shared field (an email identifier, a Supabase row ID) and the node pairs each item from input 1 with the one from input 2 sharing the same value, regardless of order. Five output settings are available: keep only matches, keep only non-matches, keep everything, or enrich specifically input 1 or input 2 with the other's fields.
  • Position — pairs items by rank (1st with 1st, 2nd with 2nd…), regardless of content. Quick to set up, but risky the moment an upstream filter can drop items on just one branch: the pairing silently shifts, with nothing flagging the error.
  • All Possible Combinations — produces the cartesian product of both inputs (every item of input 1 with every item of input 2). Useful for generating combinations (pairing every recipient with every message template, for example), rarely for simple enrichment.

SQL Query: for complex merge logic

This mode treats the inputs as tables (input1, input2…) and accepts a parameterized SQL query to combine them — joins, aggregations, complex filters. It becomes relevant when the merge logic goes beyond what a simple field match can express, without quite justifying a separate Code node.

Choose Branch: keeping only one input

Choose Branch doesn't merge anything: it passes through only one of the inputs (or an empty item) and ignores the other. Handy at the end of a workflow when two branches converge but only one should actually continue — for example after an A/B test where only the winning branch should write to the database.

Handling field conflicts (Clash Handling)

When both inputs share a field with the same name, n8n has to pick a value: by default, input 2 wins. Under Options > Clash Handling, you can flip that priority, or choose "Always Add Input Number to Field Names" to keep both values by suffixing each field with its input number — the safer default when you're not sure the "losing" value is truly redundant.

This field-pairing mechanism (Matching Fields) isn't just an n8n implementation detail: at a smaller scale, it's the same problem statistics calls record linkage — matching two records believed to describe the same entity. The reference theory on the topic, published by Fellegi and Sunter back in 1969, already formalizes the three possible outcomes of such a match: a definite link, a definite non-link, and an ambiguous case requiring an explicit decision rule. The Merge node radically simplifies that framework — it compares strict equality on a field rather than a matching probability — but the principle still holds: an explicit matching rule (Matching Fields) beats an implicit one based on order (Position), which fails silently the moment its assumptions stop holding.

Practical case: enriching an AI classification with the original data

Take the email triage workflow from the AI Inbox Pack (€79): an email goes through a Structured Output Parser that returns only categorie, resume, and expediteur_important. To route and then log the email in Supabase, you also need the subject, sender, and original body — fields the LLM never received to reproduce. The most robust construction:

  1. A Set node right after the IMAP trigger captures the useful original fields and assigns them a stable identifier (for example the email's messageId).
  2. That same identifier is carried through to the LLM's output, either by recalling it in the prompt or preserving it via $json if the LangChain node passes it through automatically.
  3. A Merge node in Combine → Matching Fields mode, with messageId as the shared field and the "Enrich Input 1" setting (the original email), glues the AI classification back onto the full email — without ever asking the model to copy a field it could have altered.

This split between what the LLM produces and what it carries along also cuts the number of tokens sent and received, which matters as volume grows — see our guide on tracking AI call costs.

Merge vs. a hand-rolled Code node

A Code node with a JavaScript loop can reproduce any of these behaviors — and that's sometimes justified for genuinely specific logic, in the spirit of our guide to JavaScript expressions in the Code node. But for common cases (matching by identifier, stacking, branch selection), the Merge node remains preferable: it's visually explicit on the canvas, requires no code to maintain, and its modes cover nearly every real-world need without a developer having to re-read a for loop every time the workflow changes.

The mistake a visual merge avoids

Outside n8n, the temptation is often to recombine two datasets by hand in a spreadsheet — paste-special, VLOOKUP, manual column sorting. Research on spreadsheet reliability going back to the 1990s shows that this kind of manual manipulation is a badly underestimated source of errors: Panko's 1998 review documents significant error rates in nearly every real-world-sized spreadsheet audited, most often tied precisely to reconciliation or copy-between-ranges operations. A Merge node configured once and versioned with the rest of the workflow (see our guide to backing up workflows with Git) eliminates that entire class of error: the pairing is deterministic and replayed identically on every run, unlike a manual manipulation redone by hand for each new file.

Wrapping up

The Merge node isn't glamorous, but it's one of the most common ones to get silently misconfigured — until a report or an alert turns up a mismatched piece of data. The simple rule to remember: Append to stack with no pairing, Combine → Matching Fields to enrich by identifier (the most common case in AI workflows), Position only when the order of both branches is guaranteed, and Choose Branch to keep just one path. The workflows in the FlowKit packs rely on these same principles to reliably combine AI output with business data — a solid foundation to reuse in your own automations.

FAQ

Frequently asked questions

What's the difference between the Append and Combine modes in the Merge node?

Append stacks items from both inputs one after another, with no pairing at all: if Input 1 has 5 items and Input 2 has 3, the output has 8, in order. Combine, by contrast, merges items pairwise (by matching field, by position, or by every possible combination): use it whenever you need to attach a piece of data from one branch to its counterpart in the other, rather than just placing them end to end.

What happens if the two branches don't have the same number of items in Position mode?

The node pairs items by rank (the first item of input 1 with the first of input 2, and so on) until the shorter input runs out: the extra items from the longer input are silently dropped. This is the most common source of error with this mode — as soon as an upstream filter can drop items on just one branch, prefer Matching Fields, which relies on an identifier rather than an order.

How do you avoid a field getting overwritten during a merge?

When both inputs share a field with the same name, n8n defaults to prioritizing input 2's value. Under Options > Clash Handling, you can flip that priority or choose 'Always Add Input Number to Field Names,' which keeps both values by suffixing each field with the number of its originating input — useful when you need to compare both versions instead of losing one.

Bundle FlowKit Complet

€269