Bedingungs-Referenz

Eine Bedingung grenzt ein, welche Instanzen eines Auslöserereignisses tatsächlich die Regel feuern. Trigger beantworten das Was ("das Mitglied hat einen Kauf getätigt"); Bedingungen beantworten das Welches ("…nur wenn der Warenkorbsumme über 20 € liegt, in der Filiale Innenstadt"). Jede Bedingung ist eine Zeile mit drei Slots — einem Feld, einem Operator und einem Wert — und Bedingungen werden mit UND verknüpft.

Diese Seite ist eine Syntax-Referenz: sie behandelt die Zeilen-Anatomie, die für jeden Feldtyp verfügbaren Operatoren, wie Bedingungen kombiniert werden und die zwei Stellen im Assistenten, an denen Bedingungen erscheinen. Die Liste, welche Felder jeder Trigger bereitstellt, lebt in der Trigger-Referenz — eine Seite pro Thema.

Wo Bedingungen erscheinen

Bedingungen tauchen an zwei Stellen im Regel-Assistenten auf, mit identischer Syntax in beiden:

• Schritt 2 — Wann → Bedingungen. Regelweite Bedingungen. Die Feldliste ist spezifisch für den gewählten Trigger — ein Kauf-Trigger stellt Warenkorb-/Filial-/Zahlungsfelder bereit, ein Gutschein-Einlöse-Trigger stellt gutscheinbezogene Felder bereit, und so weiter. Einige Trigger (Gesamtausgaben aktualisiert, Besuch aktualisiert) stellen überhaupt keine Bedingungsfelder bereit — das Ereignis selbst ist der gesamte Filter.
• Schritt 3 — Aktionen → innerhalb eines Falls. Wenn du In mehrere Fälle aufteilen aktivierst, hat jeder Fall seine eigene Bedingung-Zeile, die entscheidet, ob dieser Fall läuft. Fall-Bedingungen können zusätzlich zu den Feldern auf Ereignisebene aus Schritt 2 in Mitgliedsattribute hineinreichen (Tags, Guthaben, Aktivitätszähler, Einwilligungs-Flags) — die genaue Liste hängt vom Trigger ab. Siehe In mehrere Fälle aufteilen für das Fall-Modell.

Beide Stellen verwenden dieselbe Zeilenform und denselben Operator-Katalog. Der Unterschied ist der Geltungsbereich: Schritt-2-Bedingungen steuern die ganze Regel; Schritt-3-Bedingungen steuern einen Zweig davon.

Anatomie einer Bedingungszeile

Jede Bedingung ist eine Zeile mit drei Steuerelementen, von links nach rechts gelesen:

1. Feld — das, wonach du filterst. Die Liste wird vom Trigger definiert (in Schritt 2) oder vom Fall-Editor-Kontext (in Schritt 3).
2. Operator — wie der Wert des Feldes mit deinem verglichen wird. Die verfügbaren Operatoren hängen vom Typ des Feldes ab — ein Zahlenfeld bietet numerische Vergleicher, ein Element-Set-Feld bietet Mengenoperatoren, ein Enum-Feld bietet Mitgliedschafts-Operatoren, und so weiter.
3. Wert — wogegen du vergleichst. Die Form dieses Steuerelements folgt dem Feld und Operator: eine Zahleneingabe, ein Mehrfachauswahl-Element-Picker, ein Datum oder Datumsbereich, ein Dropdown von Enum-Werten, freier Text.

Eine weitere Bedingungszeile hinzuzufügen fügt einen weiteren Filter hinzu, nicht einen weiteren Zweig — siehe Bedingungen kombinieren unten.

Felder, Operatoren und Werte

Die drei Steuerelemente in einer Bedingungszeile arbeiten zusammen, und das Operator-Dropdown passt sich dem Feld an, das du gewählt hast. Ein numerisches Feld wie Total amount of basket bietet numerische Vergleicher (größer als, kleiner als, zwischen, und so weiter). Ein Element-Set-Feld wie Basket items bietet Mitgliedschafts-/Mengenoperatoren ("enthält mindestens N von …"). Ein Enum-Feld wie Branch oder Payment method bietet "ist eines von" / "ist keines von", damit du mehrere Werte in einer einzigen Zeile auflisten kannst. Ein Datumsfeld bietet absolute und relative Zeitvergleiche. Das Wert-Steuerelement rechts folgt entsprechend — eine Zahleneingabe, ein Element-Picker, ein Mehrfachauswahl-Dropdown, ein Datums-Picker.

Du musst keine Operator-Tabelle auswendig lernen: wähle zuerst das Feld, und die UI zeigt die Operatoren und das Wert-Steuerelement, die dazu passen. Was zählt, ist zu wissen, welche Feldtypen existieren, damit du das richtige Feld für den Filter wählen kannst, den du im Sinn hast — und die Feldbeschriftungen selbst machen den Typ meist offensichtlich (…amount… ist eine Zahl, …items ist ein Element-Set, …ID oder …type ist ein Enum, …name ist freier Text, …date ist ein Datum).

Fall-Bedingungen reichen weiter als Schritt 2

Innerhalb eines Falls in Schritt 3 enthält die Feldliste oft Mitgliedsattribute — Dinge wie Tags, Punkte-Saldo, Guthaben-Saldo, Einwilligungs-Flags, Gesamtausgaben oder Besuchszahl — zusätzlich zu den Feldern auf Ereignisebene, die in Schritt 2 verfügbar sind. So filterst du danach, wer das Mitglied ist, nicht nur was gerade passiert ist. Die genaue Liste hängt vom Trigger ab; öffne das Feld-Dropdown in einem Fall, um zu sehen, was verfügbar ist.

Bedingungen kombinieren

Bedingungen, die demselben Bedingungen-Abschnitt hinzugefügt werden, werden mit UND verknüpft — jede Bedingung muss erfüllt sein, damit die Regel (oder der Fall) feuert. Eine Kauf-Regel mit zwei Bedingungen — Total amount of basket ≥ 20 € und Branch = Innenstadt — feuert nur bei Warenkörben über 20 € in der Filiale Innenstadt. Sie feuert nicht bei einem 20-€-Warenkorb in einer anderen Filiale, noch bei einem 5-€-Warenkorb in der Innenstadt.

Für "feuere bei X ODER Y"-Logik teile die Regel stattdessen in mehrere Fälle auf — siehe nächster Abschnitt.

Wenn du ODER brauchst: verwende Fälle

Wenn die gewünschte Logik "feuere bei X ODER Y" lautet, ist der Standardweg, das zu modellieren, die Regel in Schritt 3 in mehrere Fälle aufzuteilen. Jeder Fall hat seine eigene Bedingungszeile, und die Fälle werden von oben nach unten ausgewertet — der erste passende Fall läuft. Eine Regel, die einen 10-%-Gutschein an entweder VIP-Mitglieder oder Mitglieder der Partnerorganisation geben soll, wird zu zwei Fällen: einer mit Tag = VIP, einer mit Tag = Partner-Mitglied, jeder mit seiner eigenen Rabatt hinzufügen-Aktion.

Siehe In mehrere Fälle aufteilen für das vollständige Fall-Modell.

Trigger ohne Bedingungen

Nicht jeder Trigger hat einen Bedingungen-Abschnitt. Gesamtausgaben aktualisiert und Besuch aktualisiert stellen in Schritt 2 keine Bedingungsfelder bereit — das Ereignis selbst ist der gesamte Filter. Wenn du diese eingrenzen musst (z. B. nur feuern, wenn die lebenslangen Ausgaben eines Mitglieds 500 € überschreiten, oder nur beim 10. Besuch), verwende stattdessen einen Fall in Schritt 3 mit einer Bedingung auf Mitgliedsebene, anstatt zu versuchen, in Schritt 2 zu filtern.

Das ist ein allgemeiner Rückfall: alles, was du mit den eingebauten Feldern des Triggers nicht ausdrücken kannst, versuche in einer Fall-Bedingung auszudrücken.

Stolperfallen

4 Dinge, die oft zu Verwirrung führen

• Felder hängen vom Trigger ab. Eine in der Tätigt einen Kauf-Spalte geschriebene Bedingung überlebt nicht, wenn du den Trigger auf Löst einen Gutscheincode ein änderst. Der Assistent warnt vor dem Löschen, aber das ist leicht zu überklicken. Wähle zuerst den Trigger, konfiguriere danach die Bedingungen.
• Groß-/Kleinschreibung zählt bei freien Texten. Tags und andere freie Texte werden so gespeichert, wie eingegeben, also sind Gold und GOLD unterschiedliche Übereinstimmungen. Halte dich an eine Namenskonvention, wenn du sie erstellst, damit Bedingungen später zuverlässig matchen.
• Fehlende Felder treffen nie zu. Wenn das auslösende Ereignis ein Feld nicht trägt (z. B. hat ein anonymer Kauf kein Mitglieder-Tag), wertet eine Bedingung auf dieses Feld als Nicht-Treffer aus, statt zu passen oder einen Fehler zu werfen. Regeln, die von optionalen Feldern abhängen, brauchen entweder einen sicheren Standardwert oder einen Fall, der den "unbekannt"-Pfad behandelt.
• Bedingungen warten nicht in der Schlange. Eine Bedingung wertet zum Auslösezeitpunkt gegen den Zustand in dem Moment aus. Eine Bedingung auf Tag = Großkäufer feuert nur, wenn das Mitglied beim Eintreffen des Auslöserereignisses bereits getaggt war — nicht, wenn es ein paar Minuten später von einer anderen Regel getaggt wird. Wenn du "tu X, sobald das Tag angewendet ist" brauchst, löse die nachgelagerte Regel mit Getaggt aus, statt mit einer Tag-Bedingung zu gaten.