Why n8n doesn't run parallel branches at the same time and what the Merge node actually waits for, explained according to the official documentation.
If you build a workflow in n8n that splits into multiple branches after an If or Switch node, you probably assume that these branches run at the same time and simply meet again at the Merge node. This exact assumption regularly causes confusion, because n8n does not execute branches in parallel in the sense of simultaneously, but in a fixed, traceable order. Anyone who does not know this order is puzzled by executions that seem to happen in the wrong order, by API calls that overtake each other, or by a Merge node that appears to hang forever.
The good news: the logic behind this is clearly documented and can be reliably predicted with a few basic rules. In this article we take a look at how n8n determines the execution order, what changed with version 1.0, and what the Merge node actually waits for once you understand its logic. This way you keep control over your workflows, even as they become more complex with every additional branch.
According to the official documentation on Execution Order, n8n distinguishes between two fundamentally different execution modes, depending on when a workflow was created:
This difference is the core of most misunderstandings. Anyone working with an older workflow or reusing a template from an older tutorial experiences different behavior than someone building a freshly created workflow in a current n8n version. According to the documentation, both modes can be adjusted via the workflow settings if you specifically need the respective other behavior.
For workflows from version 1.0 onwards, a fixed, traceable rule applies: n8n is guided by the position of the nodes on the canvas. Branches are processed from top to bottom. If two branches are at the same height, the horizontal position decides, with the left branch being executed first.
In practice this means: if you arrange two or three parallel branches after a Switch node in your workflow, the visual arrangement on the canvas alone determines which branch goes first, not the order in which you drew the connections, and not any internal ID either. This is especially important when individual branches have side effects, such as write access to the same table, updates to the same CRM record, or calls to the same rate-limited API. If one branch runs before the other, the result of the second branch can depend on the first, even if that was not intended in the workflow design.
The Merge node combines data from multiple sources into one stream. In Append mode, a simple but often overlooked rule applies: the node waits until all connected inputs have been executed before it continues itself. Only once every input has delivered data, or explicitly no data, does the Merge node output anything.
This explains two common observations from practice:
Since the major overhaul of the Merge node in version 0.194.0, and the extension to more than two inputs as well as the SQL query mode in version 1.49.0, it is also possible to combine more than two branches at the same time, which significantly simplifies the classic two-branch logic in larger workflows. Details on all merge modes such as Append, Combine, and Choose Branch can be found in the guide to Merging Data Streams.
A particularly tricky behavior, according to the documentation, affects exclusively workflows with the v0 legacy execution order, i.e. by default all workflows built before version 1.0. If you add a Merge node to a structure containing an If node in such a workflow, it can happen that both output streams of the If node are executed, even though the If node was actually supposed to trigger only one of the two paths. The reason: one data stream triggers the Merge node, which then also executes the other, actually inactive data stream.
This behavior was removed with version 1.0. Anyone migrating or maintaining an old workflow and observing unexplained duplicate executions after an If node will often find the cause here. Switching to the new execution order in the workflow settings usually resolves the problem reliably.
Before debugging an existing workflow, it is worth taking a quick look at the workflow settings: there you can see which execution order is currently active and switch between v0 and v1.0 if needed. For new workflows, the current logic is generally recommended, because it is more predictable and the described If-plus-Merge trap does not occur at all.
For more complex automations with multiple parallel branches and side effects, it is also worth deliberately using the canvas arrangement: place the branch that should run first at the top or on the left, and record this intent within the workflow itself, for example via a sticky note. This way it remains traceable for everyone on the team why the order was chosen exactly this way, and no one has to guess the logic again at the next rebuild. If your automations are branched to the point where the order is no longer clear at a glance, we support you with our n8n automation service to structure workflows cleanly and traceably.
No, at least not in the sense of simultaneous execution. In workflows from version 1.0 onwards, n8n processes one branch completely before the next one begins, controlled by the position of the nodes on the canvas. In older v0 workflows, execution instead proceeds node by node, layer by layer across all branches, which is also not true parallelism.
In Append mode, the Merge node waits for the execution of all connected inputs. If one of the preceding branches does not complete, for example because a condition is not met or a node throws an error, the Merge node never receives a signal from that input and accordingly produces no output.
The items at Input 1 take precedence. If the Merge node receives, for example, five items at Input 1 and ten at Input 2, it processes only five items, because Input 1 sets the upper limit for processing.
No. According to the n8n documentation, this behavior applies exclusively to workflows with the v0 legacy execution order, i.e. by default to all workflows created before version 1.0. In newly created workflows with the current execution order, this problem no longer occurs.
Yes. The execution order can be changed in the workflow settings. This is particularly useful for older, migrated workflows if you observe unexplained multiple executions after If or Switch nodes and suspect the cause lies in the outdated v0 logic.
Founder of NordFlux. Spent four years automating processes at enterprise scale at Dräger, and now brings that depth to the mid-market — pragmatic and with full data sovereignty.
Certifications
How long n8n stores execution history per plan (Starter to Enterprise), important for debugging and record-keeping obligations in accounting workflows.
Why the n8n database grows through executions and how EXECUTIONS_DATA_PRUNE, retention period, and limits automatically limit the amount of data.
When the Merge node waits for the wrong sequence, errors appear that rarely show up in testing and only surface in production. NordFlux reviews the execution order and merge logic in your n8n workflows and rebuilds them so branches converge reliably. In an initial conversation we go through your critical workflows together.
