Execution Order und Merge: warum Branches nicht laufen wie gedacht

Wenn du in n8n einen Workflow baust, der sich nach einem If- oder Switch-Node in mehrere Branches aufteilt, gehst du vermutlich davon aus, dass diese Branches gleichzeitig laufen und sich am Merge-Node einfach wieder treffen. Genau diese Annahme sorgt regelmäßig für Verwirrung, denn n8n führt Branches nicht parallel im Sinne von gleichzeitig aus, sondern nach einer festen, nachvollziehbaren Reihenfolge. Wer diese Reihenfolge nicht kennt, wundert sich über Ausführungen, die scheinbar in der falschen Reihenfolge passieren, über API-Aufrufe, die sich gegenseitig überholen, oder über einen Merge-Node, der ewig zu hängen scheint.

Die gute Nachricht: Die Logik dahinter ist klar dokumentiert und lässt sich mit ein paar Grundregeln zuverlässig vorhersagen. In diesem Artikel schauen wir uns an, wie n8n die Execution Order bestimmt, was sich mit Version 1.0 geändert hat, und worauf der Merge-Node wirklich wartet, wenn du seine Logik einmal verstanden hast. So behältst du die Kontrolle über deine Workflows, auch wenn sie mit jedem weiteren Branch komplexer werden.

Zwei Ausführungslogiken: v0 (legacy) und v1.0+

n8n unterscheidet laut der offiziellen Dokumentation zur Execution Order zwischen zwei grundsätzlich verschiedenen Ausführungsmodi, abhängig davon, wann ein Workflow angelegt wurde:

• v0 (legacy): In Workflows, die vor Version 1.0 gebaut wurden, gilt standardmäßig die alte Logik. Dabei führt n8n zuerst den jeweils ersten Node jedes Branches aus, danach den zweiten Node jedes Branches, und so weiter. Die Branches laufen also Schicht für Schicht nebeneinander her, nicht nacheinander vollständig durch.
• v1.0 und neuer: Seit Version 1.0 arbeitet n8n einen Branch komplett ab, bevor der nächste beginnt. Ein Branch läuft also vollständig durch, inklusive aller darin enthaltenen Nodes, bevor n8n zum nächsten Branch wechselt.

Dieser Unterschied ist der Kern der meisten Missverständnisse. Wer mit einem älteren Workflow arbeitet oder eine Vorlage aus einem älteren Tutorial übernimmt, erlebt ein anderes Verhalten als jemand, der einen frisch angelegten Workflow in einer aktuellen n8n-Version baut. Beide Modi lassen sich laut Dokumentation über die Workflow-Einstellungen anpassen, falls du gezielt das jeweils andere Verhalten brauchst.

Wie n8n die Reihenfolge der Branches bestimmt

Für Workflows ab Version 1.0 gilt eine feste, nachvollziehbare Regel: n8n orientiert sich an der Position der Nodes auf der Canvas. Branches werden von oben nach unten abgearbeitet. Liegen zwei Branches auf derselben Höhe, entscheidet die horizontale Position, wobei der linke Branch zuerst ausgeführt wird.

Das bedeutet praktisch: Wenn du in deinem Workflow zwei oder drei parallele Zweige nach einem Switch-Node anordnest, bestimmt allein die visuelle Anordnung auf der Canvas, welcher Zweig zuerst dran ist, nicht die Reihenfolge, in der du die Verbindungen gezogen hast, und auch nicht irgendeine interne ID. Das ist besonders wichtig, wenn einzelne Branches Seiteneffekte haben, etwa Schreibzugriffe auf dieselbe Tabelle, Aktualisierungen desselben CRM-Datensatzes oder Aufrufe derselben rate-limitierten API. Läuft ein Branch vor dem anderen, kann das Ergebnis des zweiten Branches vom ersten abhängen, selbst wenn das im Workflow-Design gar nicht so gedacht war.

Der Merge-Node: worauf er wirklich wartet

Der Merge-Node kombiniert Daten aus mehreren Quellen zu einem Stream. Im Append-Modus gilt eine einfache, aber oft übersehene Regel: Der Node wartet, bis alle verbundenen Eingänge ausgeführt wurden, bevor er selbst weiterläuft. Erst wenn jeder Input Daten oder explizit keine Daten geliefert hat, gibt der Merge-Node etwas aus.

Das erklärt zwei häufige Beobachtungen aus der Praxis:

• Ein Merge-Node, der scheinbar hängt, wartet in Wirklichkeit meist auf einen Branch, der noch nicht fertig ist oder aufgrund einer Bedingung nie ausgeführt wird.
• Bei ungleich langen Datenströmen gilt: Die Items, die an Input 1 ankommen, haben Vorrang. Erhält der Merge-Node beispielsweise fünf Items an Input 1 und zehn Items an Input 2, verarbeitet er nur fünf Items, weil Input 1 die Obergrenze vorgibt.

Seit dem größeren Umbau des Merge-Nodes in Version 0.194.0 und der Erweiterung um mehr als zwei Eingänge sowie den SQL-Query-Modus in Version 1.49.0 lassen sich außerdem mehr als zwei Branches gleichzeitig zusammenführen, was die klassische Zwei-Branch-Logik in größeren Workflows deutlich vereinfacht. Details zu allen Merge-Modi wie Append, Combine und Choose Branch findest du in der Anleitung zum Zusammenführen von Datenströmen.

Die Falle in alten Workflows: If-Node plus Merge

Besonders tückisch ist ein Verhalten, das laut Dokumentation ausschließlich Workflows mit der v0-Legacy-Ausführungsreihenfolge betrifft, also standardmäßig alle vor Version 1.0 gebauten Workflows. Fügst du in einem solchen Workflow einen Merge-Node zu einer Struktur hinzu, die einen If-Node enthält, kann es passieren, dass beide Output-Streams des If-Nodes ausgeführt werden, obwohl der If-Node eigentlich nur einen der beiden Pfade auslösen sollte. Der Grund: Ein Datenstream löst den Merge-Node aus, der daraufhin auch den anderen, eigentlich inaktiven Datenstream mit ausführt.

Dieses Verhalten wurde mit Version 1.0 entfernt. Wer also einen alten Workflow migriert oder weiterpflegt und unerklärliche doppelte Ausführungen nach einem If-Node beobachtet, findet hier oft die Ursache. Ein Wechsel auf die neue Execution Order in den Workflow-Einstellungen behebt das Problem in der Regel zuverlässig.

So prüfst und stellst du die Execution Order ein

Bevor du einen bestehenden Workflow debuggst, lohnt sich ein kurzer Check in den Workflow-Einstellungen: Dort siehst du, welche Execution Order aktuell aktiv ist, und kannst bei Bedarf zwischen v0 und v1.0 wechseln. Für neue Workflows empfiehlt sich grundsätzlich die aktuelle Logik, weil sie vorhersagbarer ist und die beschriebene If-plus-Merge-Falle gar nicht erst auftritt.

Bei komplexeren Automatisierungen mit mehreren parallelen Branches und Seiteneffekten lohnt es sich zusätzlich, die Canvas-Anordnung bewusst zu nutzen: Platziere den Branch, der zuerst laufen soll, oben beziehungsweise links, und halte diese Absicht im Workflow selbst fest, etwa über eine Sticky Note. So bleibt für jeden im Team nachvollziehbar, warum die Reihenfolge genau so gewählt wurde, und niemand muss die Logik beim nächsten Umbau neu erraten. Wenn deine Automatisierungen so verzweigt sind, dass sich die Reihenfolge nicht mehr auf einen Blick erschließt, unterstützen wir dich mit unserer n8n-Automatisierung dabei, Workflows sauber und nachvollziehbar zu strukturieren.

Häufige Fragen

Laufen Branches in n8n wirklich nicht parallel?

Nein, zumindest nicht im Sinne von gleichzeitiger Ausführung. In Workflows ab Version 1.0 arbeitet n8n einen Branch komplett ab, bevor der nächste beginnt, gesteuert durch die Position der Nodes auf der Canvas. In älteren v0-Workflows läuft stattdessen Node für Node schichtweise über alle Branches hinweg, was ebenfalls keine echte Parallelität ist.

Warum wartet mein Merge-Node scheinbar endlos?

Der Merge-Node wartet im Append-Modus auf die Ausführung aller verbundenen Eingänge. Läuft einer der vorherigen Branches nicht durch, etwa weil eine Bedingung nicht erfüllt ist oder ein Node einen Fehler wirft, bekommt der Merge-Node von diesem Input nie ein Signal und bleibt entsprechend ohne Ausgabe.

Was passiert, wenn die beiden Eingänge des Merge-Nodes unterschiedlich viele Items liefern?

Die Items an Input 1 haben Vorrang. Bekommt der Merge-Node etwa fünf Items an Input 1 und zehn an Input 2, verarbeitet er nur fünf Items, weil Input 1 die Obergrenze für die Verarbeitung vorgibt.

Betrifft die If-plus-Merge-Falle auch neue Workflows?

Nein. Laut n8n-Dokumentation gilt dieses Verhalten ausschließlich für Workflows mit der v0-Legacy-Ausführungsreihenfolge, also standardmäßig für alle vor Version 1.0 erstellten Workflows. In neu angelegten Workflows mit der aktuellen Execution Order tritt dieses Problem nicht mehr auf.

Kann ich die Execution Order nachträglich für einen bestehenden Workflow ändern?

Ja. Die Execution Order lässt sich in den Workflow-Einstellungen umstellen. Das ist besonders bei älteren, migrierten Workflows sinnvoll, wenn du unerklärliche Mehrfachausführungen nach If- oder Switch-Nodes beobachtest und die Ursache in der veralteten v0-Logik vermutest.