Execution order and merge: why branches don't run the way you think

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.

Two execution logics: v0 (legacy) and v1.0+

According to the official documentation on Execution Order, n8n distinguishes between two fundamentally different execution modes, depending on when a workflow was created:

• v0 (legacy): In workflows built before version 1.0, the old logic applies by default. n8n first executes the first node of each branch, then the second node of each branch, and so on. The branches thus run layer by layer alongside each other, not completely one after the other.
• v1.0 and newer: Since version 1.0, n8n processes one branch completely before the next one begins. A branch thus runs through completely, including all nodes contained in it, before n8n switches to the next branch.

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.

How n8n determines the order of branches

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: what it actually waits for

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:

• A Merge node that appears to hang is in reality usually waiting for a branch that is not yet finished or that never runs due to a condition.
• With streams of unequal length, the following applies: the items arriving at Input 1 take precedence. If the Merge node receives, for example, five items at Input 1 and ten items at Input 2, it processes only five items, because Input 1 sets the upper limit.

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.

The trap in old workflows: If node plus Merge

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.

How to check and set the execution order

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.

Frequently asked questions

Do branches in n8n really not run in parallel?

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.

Why does my Merge node seem to wait endlessly?

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.

What happens if the two inputs of the Merge node deliver different numbers of items?

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.

Does the If-plus-Merge trap also affect new workflows?

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.

Can I change the execution order for an existing workflow afterwards?

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.