IF Node (n8n)

Die Anatomie einer Bedingung

Du musst drei Dinge einstellen:

1. Value 1: Was willst du prüfen? (z. B. {{ $json.bestellwert }}).
2. Operator: Wie willst du prüfen? (z. B. > larger than, == equal to, contains).
3. Value 2: Wogegen vergleichst du? (z. B. 50).

Beispiel: "Wenn Bestellwert > 50 Euro ist, dann gehe zu 'True' (Versandkostenfrei)."

Mehrfach-Bedingungen (AND / OR)

Du kannst auch komplexere Logik bauen:

• AND (Und): "Kunde ist VIP" UND "Bestellwert > 100". (Beides muss stimmen).
• OR (Oder): "Kunde ist VIP" ODER "Bestellwert > 100". (Eins von beiden reicht).

1. Type Casting (Zahlen vs. Text)

Ein klassischer Anfängerfehler: Du vergleichst 100 (Zahl) mit "100" (Text). Der Computer sagt: "Falsch! Das eine ist Mathe, das andere ein Wort." Im IF Node musst du darauf achten, ob die Daten als String oder Number ankommen. Sonst feuert der Node immer "False".

2. Switch Node (Die bessere Alternative)

Wenn du eine Weiche mit mehr als 2 Ausgängen brauchst, nimm nicht 5 IF-Nodes hintereinander ("Ist es A? Nein. Ist es B? Nein..."). Nimm den Switch Node. Dort kannst du 4 Ausgänge definieren:

• Route 1: "Support"
• Route 2: "Sales"
• Route 3: "Buchhaltung"
• Fallback: "Sonstiges"

3. Filtern vs. Routing

Manchmal willst du Daten gar nicht aufteilen, sondern schlechte Daten einfach wegwerfen. Dafür gibt es den Filter Node. Er hat nur einen Ausgang ("True"). Alles was "False" ist, stirbt einfach. Das macht den Workflow übersichtlicher, wenn du den "Nein"-Pfad eh nicht brauchst.

Regex (Regular Expressions) in Bedingungen

Das Dropdown mit contains oder starts_with reicht für simple Checks, scheitert aber an Mustern ("Ist das String-Format eine valide DE-Postleitzahl?"). Im IF Node kannst du als Operator "Regex" auswählen (String: Regex match). Gibst du nun als Value 2 den Ausdruck ^[0-9]{5}$ an, feuert der IF-Node das Item nur dann in den "True"-Kanal, wenn die Input-Daten exakt 5 Ziffern annehmen. Regex ist das ultimative Filtermesser für unsaubere JSON-Payloads von Webhooks.

Date & Time Comparisons (Das Format-Desaster)

"Vergleiche, ob das Datum aus dem CRM älter als 30 Tage ist." Das ist oft ein Albtraum, wenn das CRM 12/05/2023 schickt, n8n aber intern ISO-8601 erwartet (2023-05-12T00:00:00Z). Ein einfacher String-Vergleich im IF-Node > 30 schlägt komplett fehl (String vs. Number vs. Date). Lösung: Moderne n8n-IF-Nodes haben den Typ Date & Time. Der Node nutzt intern Luxon (die moderne Moment.js Variante). Er parst beide Seiten in Unix-Timestamps (Millisekunden) und vergleicht diese mathematisch absolut präzise, unabhängig von Zeitzonenverschiebungen (Offset).

Abstract Syntax Tree (AST) & Code Execution

Was tut n8n, wenn du {{ $json.price * 1.19 > 100 }} als Expression eingibst? Früher rief n8n direkt die berüchtigte eval() Funktion in Node.js aus. Das war ein eklatantes Security-Risiko (RCE - Remote Code Execution), da man bösartigen JS-Code in die Variable schieben konnte. Heute baut n8n einen Abstract Syntax Tree (AST) auf. Die Expression wird von einem Parser in ihre Bestandteile zerlegt (Tokenization) und in einer streng isolierten Sandbox (wie vm2 oder Sandboxie) evaluiert. Sie hat keinerlei Zugriff auf das Betriebssystem (fs oder process.env), sondern operiert exklusiv auf dem aktuellen $json Scope-Objekt, was die Ausführung deterministisch und hacker-sicher macht.