Begriff
Workflow (n8n)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Ein Workflow ist der fertige Bauplan für eine Automatisierung. Stell dir eine Modell-Eisenbahn vor:
- Die Schienen sind die Verbindungen.
- Die Weichen und Bahnhöfe sind die Nodes.
- Der Zug ist das Datenpaket, das durchfährt.
Wenn du in n8n eine neue Automatisierung baust, legst du einen leeren Workflow an (die weiße Leinwand). Dann platzierst du den Startpunkt (Trigger) und sagst: "Wenn der Zug hier losfährt, soll er nach rechts, dann anhalten, dann hupen."
Merksatz: Die visuelle Abfolge (Kette) von Schritten, die n8n nacheinander abarbeitet.
Struktur eines Workflows
Ein Workflow besteht immer aus mindestens zwei Teilen:
- Trigger (Der Auslöser):
"Wann soll ich starten?"
- Zeit: Jeden Tag um 8:00 Uhr (Cron).
- Event: Wenn eine E-Mail kommt (Webhook).
- Manuell: Wenn ich den Knopf drücke.
- Logic & Actions (Was soll ich tun?):
Die eigentliche Arbeit.
- Daten filtern (IF-Node).
- Daten senden (HTTP-Request).
- Daten ändern (Set-Node).
Wenn ein Ablauf komplexer wird, trennst du Entscheidungen, Schleifen und Fehlerpfade bewusst: IF Node (n8n) verzweigt nach Bedingungen, n8n Loop Node (SplitLab) verarbeitet Listen kontrolliert, und ein Error Workflow (n8n) sorgt dafür, dass Fehler nicht still verschwinden.
Active vs. Inactive
Das ist die wichtigste Einstellung oben rechts in der Ecke.
- Inactive (Standard): Der Workflow schläft. Er reagiert nicht auf Trigger (z. B. Webhooks). Du kannst ihn nur manuell testen ("Execute Workflow").
- Active (Live): Der Workflow ist scharf geschaltet. Er lauscht im Hintergrund 24/7. Jedes Mal, wenn der Trigger feuert, rennt er los. Achtung: Vergiss oft, ihn zu aktivieren, und wundere dich dann, warum nichts passiert!
1. JSON-Sharing
Workflows sind in n8n portable Textdateien.
Du kannst jeden Workflow kopieren (Strg+C) und in einen Texteditor einfügen. Du siehst dann riesiges JSON-Gekröse.
Das ist genial, weil du Workflows per E-Mail, Slack oder GitHub mit Kollegen teilen kannst.
Es gibt Bibliotheken voller fertiger Workflows. Du kopierst das JSON, fügst es bei dir ein (Strg+V), und zack hast du die komplette Logik inklusive aller Einstellungen (außer Passwörter).
2. Error Handling (Try-Catch)
Was passiert, wenn eine API mal down ist? Standardmäßig stoppt der Workflow und schreit "Error!". Ein robuster Workflow nutzt den Error Trigger. Das ist wie ein Airbag.
- Du definierst einen zweiten, kleinen Workflow (den "Error Workflow").
- Wenn im Haupt-Workflow irgendwas schiefgeht, springt der Error Workflow an.
- Der schickt dir dann eine Nachricht in Slack: "Achtung, Workflow XYZ ist gerade gegen die Wand gefahren! Grund: API Timeout."
3. Execution Data (Lebensdauer)
Jeder Lauf eines Workflows erzeugt Daten (Logs). "Wann lief er? Was kam rein? Was ging raus?" Das verbraucht Speicherplatz. In den Workflow-Settings kannst du einstellen:
- "Speichere nur fehlgeschlagene Ausführungen" (Spart Platz).
- "Lösche Logs nach 3 Tagen" (Pruning). Das ist essenziell für Self-Hosting, sonst läuft deine Festplatte voll.
1. Sub-Workflows (Execute Workflow Node)
Wenn ein Workflow 150 Nodes erreicht, wird der Browser-Tab langsam (DOM-Overload) und das Debugging ein Albtraum.
Das Enterprise-Pattern lautet: Sub-Workflows.
Du trennst Logik auf. Workflow A ("Empfange Shopify Order") ruft Workflow B ("Formatiere und Sende Slack Alert") via dem "Execute Workflow"-Node synchron auf. Workflow B agiert wie eine wiederverwendbare Funktion (Call By Value). Er macht seine Arbeit, übergibt die modifizierten JSON-Items per return an Workflow A zurück. So können 10 verschiedene Workflows denselben Fehler-Reporting-Workflow zentral konsumieren (DRY-Prinzip).
2. Stateful Execution (Wait Node)
Wie baut man in n8n ein "Warte 3 Tage und schicke dann eine Follow-Up E-Mail"?
Ein simpler setTimeout im RAM würde bei Node.js und n8n-Container-Restarts gnadenlos vernichtet werden.
Der Wait-Node friert den gesamten Workflow-State serialisiert ein und schreibt ihn in die Postgres-DB (Status: waiting). Der aktive NodeJS-Prozess wird physikalisch beendet (Zero RAM Usage). Ein cronähnlicher Watcher in der DB weckt den State exakt nach 72 Stunden auf, lädt den Payload in den RAM und resumes die Exekution ab Schritt 4. So überleben tausende parallele Drip-Kampagnen Serverreboots.
3. Concurrency und Race Conditions
Wenn der Webhook "Neue Bestellung" 50x pro Sekunde feuert, startet n8n 50 parallele Executions in der V8-Event-Loop. Wenn zwei Executions gleichzeitig versuchen, den Google-Sheet "Bestellnummer" hochzuzählen, überschreiben sie sich gegenseitig (Race Condition). n8n bietet dafür rudimentär Concurrency Limits an (z.B. begrenze den Workflow auf max. 1 Execution gleichzeitig). Alles andere wandert in ein Queuing System (RabbitMQ/Redis via Bull), welches in der Multi-Main-Worker Architektur gestartet wird.
Quick-Check
Was ist der Unterschied zwischen einem aktiven und inaktiven Workflow?
Ein inaktiver Workflow reagiert nicht auf automatische Trigger (nur manuell). Ein aktiver Workflow läuft live im Hintergrund.Wie kannst du einen komplexen Workflow an einen Kollegen senden, ohne Screenshots zu machen?
Du kopierst die Nodes (Strg+A, Strg+C) und schickst ihm den JSON-Text. Er fügt ihn bei sich ein.Warum sollte man "Execution Data" nicht für immer speichern?
Weil Protokolle Speicherplatz fressen. Bei tausenden Ausführungen pro Tag läuft der Server voll.