Sub-Workflows: Module statt Monolith

Ein Workflow mit fünfzig Nodes, drei verschachtelten IF-Zweigen und fünf verschiedenen Datenquellen sieht auf den ersten Blick beeindruckend aus, ist in der Praxis aber ein Wartungsalbtraum. Jede kleine Änderung an der Rechnungsprüfung reißt den ganzen Kundenbestellungs-Workflow auf, jeder neue Kollege braucht eine Stunde, nur um zu verstehen, was der Workflow eigentlich tut. Genau für dieses Problem gibt es in n8n Sub-Workflows: Ein Workflow ruft einen anderen auf, bekommt dessen Ergebnis zurück und macht weiter, ganz ähnlich wie eine Funktion in klassischem Code.

Statt eines Monolithen entstehen so kleine, in sich geschlossene Bausteine, die einzeln getestet, einzeln geändert und in mehreren Workflows wiederverwendet werden können. Dieser Artikel zeigt, wie Sub-Workflows in n8n technisch funktionieren, wie Du eine bestehende Automatisierung in Module aufteilst und worauf Du bei Datenfluss und Fehlerbehandlung achten musst. Stand: Juli 2026.

Was ein Sub-Workflow eigentlich ist

Laut der n8n-Dokumentation zum Aufteilen von Workflows kannst Du einen Workflow aus einem anderen Workflow heraus aufrufen. Das erlaubt Dir, modulare, microservice-ähnliche Workflows zu bauen, statt alles in einen einzigen riesigen Ablauf zu packen. Ein Sub-Workflow ist dabei nichts anderes als ein ganz normaler n8n-Workflow, der aber speziell dafür gebaut ist, von einem anderen Workflow angestoßen zu werden und ein Ergebnis zurückzugeben.

Zwei Nodes bilden das Fundament dieser Beziehung: Im aufrufenden, übergeordneten Workflow sitzt der Execute Sub-workflow Node, im aufgerufenen Workflow steht ganz am Anfang der Execute Sub-workflow Trigger Node, auch als "When Executed by Another Workflow" bezeichnet. Der Trigger ist Pflicht: Ohne ihn kann ein Sub-Workflow nicht von außen gestartet werden.

Warum sich die Aufteilung lohnt

Die Vorteile sind in der Praxis spürbar, nicht nur theoretischer Natur:

• Wiederverwendbarkeit: Eine Logik wie "Kundendaten validieren" oder "PDF-Rechnung erzeugen" schreibst Du einmal als Sub-Workflow und rufst sie aus beliebig vielen übergeordneten Workflows auf, statt sie mehrfach zu kopieren.
• Wartbarkeit: Ändert sich eine Geschäftsregel, passt Du sie an genau einer Stelle an, im Sub-Workflow, statt in fünf verschiedenen Kopien nach jeder Instanz zu suchen.
• Übersichtlichkeit: Ein Hauptworkflow mit sieben klar benannten Sub-Workflow-Aufrufen ist auf einen Blick verständlicher als fünfzig Nodes auf einer Leinwand.
• Ressourcenschonung bei großen Workflows: Laut Dokumentation zählen Sub-Workflow-Ausführungen nicht gegen das monatliche Ausführungs- oder aktive Workflow-Limit Deines Plans, was bei Speicherproblemen in sehr großen Workflows zusätzlich hilft.
• Getrennte Verantwortlichkeiten: Ein Team kann an der Bestelllogik arbeiten, ein anderes am E-Mail-Versand, ohne sich gegenseitig im selben Workflow in die Quere zu kommen.

Wer im Unternehmen viele wiederkehrende Abläufe automatisiert, etwa Angebots- oder Rechnungsprozesse, profitiert besonders von dieser Modularisierung. Mehr zu solchen Automatisierungen findest Du unter digitale Mitarbeiter bei NordFlux.

Sub-Workflow bauen: der Trigger-Node

Um einen Workflow als Sub-Workflow nutzbar zu machen, fügst Du ganz am Anfang den Execute Sub-workflow Trigger Node ein. Er muss laut Dokumentation der erste Node im Workflow sein. Für die erwarteten Eingabedaten stehen drei Modi zur Auswahl:

• Define using fields: Du legst einzelne Feldnamen und deren Datentypen fest, die der aufrufende Workflow liefern muss.
• Define using JSON example: Du gibst ein Beispiel-JSON an, aus dem n8n Struktur und Typen ableitet.
• Accept all data: Der Trigger nimmt jede eingehende Datenstruktur ohne Vorgaben entgegen.

Für produktiv genutzte Sub-Workflows ist die erste oder zweite Variante meist die bessere Wahl, weil klar definierte Eingaben Fehler früh sichtbar machen, statt sie erst mitten im Ablauf auffliegen zu lassen.

Sub-Workflow aufrufen: der Execute Sub-workflow Node

Im übergeordneten Workflow bindest Du den Execute Sub-workflow Node ein und legst fest, welcher Workflow ausgeführt werden soll. Laut der n8n-Dokumentation zum Execute Sub-workflow Node stehen dafür vier Quellen zur Verfügung:

• Database: Auswahl aus einer Liste vorhandener Workflows oder direkte Eingabe der Workflow-ID.
• Local File: Ausführung eines Workflows, der als JSON-Datei lokal auf dem n8n-Host liegt.
• Parameter: Der Workflow-Code wird direkt als JSON in den Node eingegeben.
• URL: Ein Workflow wird von einer Web-Adresse geladen und ausgeführt.

Zusätzlich legst Du den Ausführungsmodus fest: entweder alle Eingabe-Items in einer einzigen Ausführung an den Sub-Workflow übergeben, oder den Sub-Workflow einmal je Eingabe-Item separat starten. Über die Option Wait for Sub-Workflow Completion bestimmst Du, ob der übergeordnete Workflow auf das Ergebnis wartet oder sofort weiterläuft, ohne auf den Abschluss zu warten.

Datenfluss zwischen Haupt- und Sub-Workflow

Daten wandern in einem klaren, zweistufigen Muster: Der Execute Sub-workflow Node im Hauptworkflow schickt seine Daten an den Execute Sub-workflow Trigger Node im aufgerufenen Workflow. Dort laufen sie durch die weiteren Nodes des Sub-Workflows, und der letzte Node im Sub-Workflow schickt sein Ergebnis zurück an den Execute Sub-workflow Node im Hauptworkflow. Über den Link "View sub-execution" lässt sich diese Ausführung in beide Richtungen nachvollziehen, ein wichtiges Werkzeug beim Debuggen verschachtelter Automatisierungen.

Eine wichtige Einschränkung solltest Du kennen: Enthält der Sub-Workflow Fehler, kann der übergeordnete Workflow ihn nicht erfolgreich auslösen. Ein sauber laufender, getesteter Sub-Workflow ist deshalb Voraussetzung, nicht Kür.

Bestehenden Workflow in einen Sub-Workflow umwandeln

Wer nicht bei null anfangen will, kann vorhandene Workflow-Teile direkt umbauen. Laut der n8n-Dokumentation zur Umwandlung in Sub-Workflows markierst Du dafür die gewünschten Nodes auf der Zeichenfläche, klickst mit der rechten Maustaste auf den Hintergrund und wählst "Convert to sub-workflow" aus dem Kontextmenü.

Für die Auswahl gelten feste Regeln:

• Trigger-Nodes dürfen nicht Teil der Auswahl sein.
• Die Auswahl muss zusammenhängend sein, mit gültigen Verbindungen zum Rest des Workflows.
• Es darf nur einen Einstiegspunkt geben, also nur einen Node, der Verbindungen von außerhalb der Auswahl empfängt, und das über einen einzigen Eingabezweig ohne Merge-Node.
• Ebenso darf es nur einen Ausstiegspunkt geben, einen einzigen Node mit Verbindungen nach außen, über einen einzigen Ausgabezweig ohne IF-Node.
• Alle Nodes zwischen Ein- und Ausstiegspunkt müssen in der Auswahl enthalten sein.

Ein paar Stolperfallen solltest Du zusätzlich einplanen: Die Funktion ist laut Dokumentation ab n8n-Version 1.97.0 auf allen Plänen verfügbar, neu erzeugte Sub-Workflows nutzen aber die v1-Ausführungsreihenfolge, die von den Einstellungen des ursprünglichen Workflows abweichen kann. Bei KI-Nodes ist die Unterstützung eingeschränkt, verbundene Sub-Nodes müssen komplett mit ausgewählt werden und gemeinsam genutzte Nodes müssen unter Umständen dupliziert werden. Auch Zugriffsfunktionen wie `first()`, `last()` und `all()` sowie die Funktion `itemMatching`, die feste numerische Indizes statt Ausdrücke verlangt, solltest Du nach der Umwandlung genau prüfen, bevor Du den neuen Sub-Workflow produktiv schaltest.

Praxisbeispiel: Angebotsprozess in Module aufteilen

Stell Dir einen Workflow vor, der eingehende Anfragen prüft, ein Angebot erstellt, es als PDF formatiert und per E-Mail verschickt. Statt das alles in einem Ablauf zu bündeln, lässt sich das sauber aufteilen: ein Sub-Workflow "Kundendaten validieren", ein zweiter "Angebot berechnen", ein dritter "PDF erzeugen und versenden". Der Hauptworkflow ruft diese drei Module nacheinander auf und reicht die Ergebnisse weiter. Ändert sich später die Preislogik, wird nur der zweite Sub-Workflow angepasst, alles andere bleibt unberührt. Genau diese Art von modularer, gut wartbarer Automatisierung setzt NordFlux für KMU-Kunden um, damit Du auch bei wachsender Komplexität die Kontrolle über Deine Prozesse behältst.

Häufige Fragen

Wann lohnt sich ein Sub-Workflow und wann nicht?

Ein Sub-Workflow lohnt sich, sobald eine Logik mehrfach gebraucht wird oder ein Workflow so groß wird, dass er unübersichtlich ist. Für sehr kleine, einmalig genutzte Abläufe mit wenigen Nodes lohnt sich der zusätzliche Aufruf-Overhead dagegen selten, hier reicht ein einzelner Workflow meist aus.

Kann ein Sub-Workflow selbst wieder einen Sub-Workflow aufrufen?

Ja, Sub-Workflows lassen sich verschachteln, ein aufgerufener Workflow kann selbst wieder einen Execute Sub-workflow Node enthalten. In der Praxis solltest Du die Verschachtelungstiefe im Blick behalten, damit die Struktur nachvollziehbar bleibt und sich Fehler beim Debuggen noch zuordnen lassen.

Was passiert, wenn der Sub-Workflow fehlschlägt?

Enthält der Sub-Workflow Fehler, kann der übergeordnete Workflow ihn laut Dokumentation nicht erfolgreich auslösen. Deshalb sollte jeder Sub-Workflow für sich getestet und mit sauberer Fehlerbehandlung ausgestattet sein, bevor er von anderen Workflows abhängig gemacht wird.

Zählen Sub-Workflow-Ausführungen zu meinem n8n-Limit?

Laut n8n-Dokumentation zählen Sub-Workflow-Ausführungen nicht gegen das monatliche Ausführungs- oder aktive Workflow-Limit Deines Plans. Das macht Module besonders attraktiv, wenn Du viele wiederkehrende Teilabläufe hast, die sonst einzeln gegen Dein Limit laufen würden.

Kann ich einen bestehenden Workflow nachträglich in Module aufteilen?

Ja. Über die Funktion "Convert to sub-workflow" markierst Du zusammenhängende Nodes mit genau einem Ein- und einem Ausstiegspunkt und wandelst sie per Rechtsklick in einen eigenständigen Sub-Workflow um. Danach solltest Du Ausführungsreihenfolge und verwendete Ausdrücke im neuen Sub-Workflow noch einmal prüfen.