n8n parallel branches execution order canvas position

Test record: found by Fractional HQ on 10 November 2026 in a lead-handling template, from its result. n8n version not recorded. No minimal example was built and the canvas-flip test has no recorded result. Not tested: the execution order setting, other n8n versions, nodes with more than two wires.

Symptom

On 10 November 2026 we tidied the layout of a lead-handling template, positions only, with no wires touched. Afterwards the node that marked a lead as told ran above the node that created the lead. It silently matched nothing, because the lead did not exist yet when it ran. Nothing failed and no error appeared. The lead simply never got marked.

How to reproduce it

Take a node with two outgoing wires, one to a node that creates a record and one to a node that updates that record by a key. Drag the updating node above the creating one and run the workflow. Based on what we saw, the updating branch should now run first. We did not build a minimal example like that, since we found this in the template itself, so we can only describe the shape of the failure.

n8n's own "Tidy up" does the same thing as a manual drag. A pass that only changes positions is enough to reorder the branches.

Cause, as far as we know

Execution order for sibling branches follows their vertical position on the canvas, top first. That is what we observed, and we did not look for the rule in the source or the documentation.

The fix

We stopped relying on position for anything where order matters, and we made the order explicit in the wires. If node B must run after node A, A's output goes to B and B's output goes onward, so a single node never fans out to two branches that depend on each other. The rule we now review each template against is this: no node output has two outgoing wires in a place where the order of those branches matters.

To prove that a layout change is safe, we flip the canvas vertically in a test copy of the workflow and run it again. If the result changes, the template was leaning on position. That is the test we set for ourselves after this, and we have no recorded result from it to show you. A diff with the positions stripped out comes back empty even for the broken layout, so an empty stripped diff says nothing about whether behaviour is the same.

A related trap from earlier runs

On a separate occasion in October 2026, an append Merge node fired as soon as its first inputs were ready and fired again when a failure branch finished, which produced two summary emails. That was a different problem, and we mention it only because it showed up in the same kind of branching template: we write the summary before sending and let each failure branch send its own alert once.

What we did not establish

We did not test whether the order depends on the workflow's execution order setting, though the Merge case above was seen under execution order v1. We did not test other n8n versions, and we did not check the behaviour on branches with more than two wires. The one case we have is the lead template, found by its result, with no recorded exact version.

Written by Fractional HQ from its own runs. If your n8n behaves differently, email hello@fractionalhq.uk and we will correct the note.