Aktionen & Entscheidungen

Diese fügen Sie auf der Builder-Arbeitsfläche hinzu. Aktionen führen Seiteneffekte aus. Entscheidungen teilen den Pfad in einen Ja-Zweig und einen Nein-Zweig. Diese Seite ist der Katalog und die Regeln.

Aktionen: die Schritte, die Arbeit erledigen

Eine Aktion führt einen Seiteneffekt aus und lässt den Workflow danach weiterlaufen. Die verfügbaren Aktionen sind nach Bereich gruppiert; die gängigen:

Kommunikation

• Eine E-Mail senden, über eine Vorlage oder inline verfasst, mit Anhängen.
• Eine SMS senden.
• Eine WhatsApp-Nachricht senden an Nummern, von denen Sie bereits eine eingehende Nachricht haben.
• Einen Nutzer benachrichtigen: eine Bildschirmbenachrichtigung anzeigen oder einen angemeldeten Nutzer weiterleiten.

Datensätze

• Einen Datensatz anlegen: einen neuen Lead, Kontakt, Deal, ein Ticket, eine Rechnung, Aufgabe, Notiz oder einen eigenen Datensatz. Die ID des neuen Datensatzes steht späteren Schritten zur Verfügung, siehe Daten weitergeben.
• Einen Datensatz aktualisieren: Felder, Phase, Besitzer oder Tags ändern. Wenn Sie die Phase eines Deals auf eine Gewonnen- oder Verloren-Phase setzen, werden die Gewonnen/Verloren-Flags korrekt gesetzt.
• Eine Aufgabe anlegen oder eine Notiz hinzufügen.
• Untergeordnete Datensätze verarbeiten: Datensätze, die mit dem aktuellen verknüpft sind, in einen Ziel-Workflow schieben.
• Untergeordnete Datensätze löschen: verknüpfte Datensätze entfernen (kein Rückgängig, wird in der Prüfspur protokolliert).

Dokumente

• Ein PDF generieren für eine Rechnung oder ein Angebot.
• Mit Anhängen arbeiten: Dateien kopieren oder anhängen.

Logik und Integration

• Einen Webhook aufrufen: eine HTTP-Anfrage an ein anderes System senden, mit einem Body, den Sie in Flexie Scripting verfassen. Kann so eingestellt werden, dass bei Fehlschlag erneut versucht wird, siehe unten.
• Einen Wert speichern: einen berechneten Wert ablegen, damit spätere Schritte ihn verwenden können ({{ __data.… }}).
• Gemeinsames Gedächtnis setzen: einen Wert in einem kurzlebigen gemeinsamen Gedächtnis ablegen, das andere Workflows mit memoryGet(...) lesen können.
• In einen anderen Workflow verschieben: den Datensatz aus diesem Workflow entfernen und/oder zu einem anderen hinzufügen.
• Ein KI-Schritt: Geben Sie Flexie AI in einfachen Worten eine Aufgabe („prüfe diesen Deal und kennzeichne Risiken", „entwirf eine Antwort"), und sie erledigt diese Aufgabe unbeaufsichtigt bei jedem Lauf des Workflows. Siehe Flexie AI.

Welche Aktionen Sie genau sehen, hängt vom Datensatztyp ab und davon, welche Funktionen für Ihr Konto aktiviert sind.

Wie das Ergebnis einer Aktion den Flow steuert

Jede Aktion gelingt oder schlägt fehl, und dieses Ergebnis bestimmt, was als Nächstes läuft:

• Erfolg → der „Ja"-Pfad. Die mit der Aktion verbundenen Schritte laufen.
• Fehlschlag → der „Nein"-Pfad. Hat die Aktion einen separaten Fehlerzweig, wird dieser genommen; andernfalls endet der Zweig dort.

Wenn eine Aktion fehlschlägt

Standardmäßig stoppt eine fehlgeschlagene Aktion ihren Zweig (und wird in den Aktivitätsprotokollen als fehlgeschlagen erfasst). Für Best-Effort-Schritte, deren Fehlschlag nicht alles anhalten soll (eine optionale Benachrichtigung, eine unkritische Anreicherung), können Sie die Aktion auf Fehler ignorieren setzen: Der Zweig läuft dann weiter, als wäre er erfolgreich gewesen, während der Fehlschlag zur Nachvollziehbarkeit weiterhin erfasst wird.

Fehler-ignorieren ist für „Nice-to-have"-Schritte gedacht. Es ist kein erneuter Versuch und nicht für Schritte, von denen spätere Schritte abhängen.

Erneute Versuche

Die Workflow-Engine wiederholt Schritte nicht automatisch. Einige wenige Aktionen setzen dort, wo es sicher ist, ihren eigenen erneuten Versuch um, allen voran die Webhook-Aktion, die Sie anweisen können, eine fehlgeschlagene Anfrage eine festgelegte Anzahl von Malen zu wiederholen. Für alles andere gilt: Ein Schritt läuft einmal; schlägt er fehl, wird er protokolliert und der Zweig folgt dem Fehlerpfad. (Der E-Mail-Versand hat seinen eigenen erneuten Versuch auf Zustellungsebene, getrennt vom Workflow.)

Entscheidungen: die Schritte, die wählen

Eine Entscheidung prüft eine Bedingung und leitet den Datensatz entweder in ihren Ja-Zweig oder ihren Nein-Zweig. Es gibt vier Arten, jede für etwas anderes geeignet, das geprüft werden soll:

Entscheidung	Prüft …	Verwenden Sie sie für
Datensatzbedingung	die Feldwerte des aktuellen Datensatzes	„ist dieser Deal über 10.000?", „ist der Kontakt in Deutschland?"
Zeitbedingung	das aktuelle Datum und die Uhrzeit	„ist Werktag?", „ist es nach 9 Uhr?", „ist Januar?"
Virtuelle Bedingung	Werte unter __data, alles, was ein früherer Schritt gespeichert hat, oder jedes Feld, das mit einer eingehenden Web-Anfrage mitkommt	Verzweigung anhand eines Webhook-Payloads oder eines gespeicherten Werts, siehe Dynamische Endpunkte
Core-Entscheidung	eine allgemeine Bedingung	eine einfachere Variante der Datensatzbedingung

Datensatzbedingungen: den Filter bauen

Eine Datensatzbedingung nutzt denselben Filter-Builder, den Sie aus Smart Lists kennen: Wählen Sie ein Feld, einen Operator und einen Wert. Sie können mehrere Regeln mit UND und ODER kombinieren und Gruppen verschachteln.

Der vollständige Operatoren-Katalog

Operator	Bedeutung
equal / not_equal	Wert stimmt überein / stimmt nicht überein
less / less_or_equal	Kleiner als / kleiner oder gleich
greater / greater_or_equal	Größer als / größer oder gleich
less_than_now / greater_than_now	Ein Datetime-Feld im Vergleich zum aktuellen Moment
less_than_today / greater_than_today	Ein Datumsfeld im Vergleich zu heute
between / not_between	Liegt innerhalb / außerhalb eines Bereichs (Sie geben die beiden Endpunkte an)
begins_with / not_begins_with	Text beginnt / beginnt nicht mit dem Wert
ends_with / not_ends_with	Text endet / endet nicht mit dem Wert
contains / not_contains	Text enthält / enthält nicht den Wert
in / not_in	Wert ist einer von / ist keiner aus einer kommagetrennten Liste
in_list / not_in_list	Datensatz ist in / ist nicht in einer gespeicherten Smart List
includes / excludes	Für Felder mit mehreren Werten (Tags, Mehrfachauswahl): mindestens einer der / keiner der gewählten Werte ist vorhanden
is_empty / is_not_empty	Feld ist leer / hat einen Wert
is_null / is_not_null	Feld ist NULL / ist nicht NULL (bei manchen Feldtypen fein unterschiedlich von leer)
is_subscribed / is_not_subscribed	Datensatz ist / ist nicht abonniert (für Felder, die mit Abos verknüpft sind)
is / is_not	Ein benanntes relatives Zeitfenster, siehe die Tabelle unten
in_polygon	Ein Punkt-Feld liegt innerhalb einer Polygon-Form (geografisches Filtern)

Wertlose Operatoren brauchen trotzdem einen Wert-Schlüssel. Für is_empty, is_not_empty, is_null, is_not_null setzt der Filter-Builder den Wert automatisch auf „none". Sie wählen nur den Operator.

Relative Datumsfenster: is und is_not

Wenn Sie den Operator is oder is_not auf einem Datums- oder Datetime-Feld wählen, treffen Sie eine Auswahl aus einer Liste benannter Fenster. Alle Fenster werden in der Zeitzone Ihres Kontos ausgewertet:

Auflösung	Verfügbare Werte
Tag	today, yesterday, next_day, birthday_today
Stunde (Datetime)	last_hour, last_12_hours, last_24_hours, next_hour, next_12_hours, next_24_hours
Woche	this_week, last_week, next_week
Monat	this_month, last_month, next_month
Quartal	this_quarter, last_quarter, next_quarter
Jahr	this_year, last_year, next_year
Rollende Vergangenheit	last_7_days, last_14_days, last_30_days, last_60_days, last_90_days
Rollende Zukunft	next_7_days, next_14_days, next_30_days, next_60_days, next_90_days

birthday_today trifft unabhängig vom Jahr zu (es vergleicht Monat und Tag), womit Sie „Geburtstag heute"-Automatisierungen bauen.

Zeitbedingungen

Eine Zeitbedingung vergleicht den aktuellen Moment mit Regeln, die Sie festlegen. Es gibt sieben Zeitfelder zur Auswahl, jedes ein anderer Ausschnitt von „jetzt":

Feld	Was es zum Auswertungszeitpunkt ist
full_date	Das aktuelle Datum und die Uhrzeit (Y-m-d H:i:s)
date_only	Das heutige Datum (Y-m-d)
time_only	Die aktuelle Uhrzeit
year	Das aktuelle Jahr als Zahl
month	Der aktuelle Monat als kleingeschriebener Name (january, ..., december)
date	Der aktuelle Tag des Monats als Zahl (1 bis 31)
day	Der aktuelle Wochentag als kleingeschriebener Name (monday, ..., sunday)

Kombinieren Sie diese mit denselben Operatoren wie Datensatzbedingungen (equal, between, is_empty usw.). Zum Beispiel ist „nur Mo bis Fr zwischen 09:00 und 17:00 fortfahren" eine Zeitbedingung mit zwei Regeln, verbunden durch UND.

Zeitbereiche, die über Mitternacht reichen (z. B. between 23:00:00 and 06:00:00), werden korrekt behandelt. Die Engine behandelt sie als umlaufendes Fenster, das beide Seiten von Mitternacht abdeckt, nicht als leeren Bereich.

Wenn Sie einen Schritt (statt eines ganzen Zweigs) auf ein Fenster oder einen Tag beschränken müssen, verwenden Sie die schritteigene Einstellung eingeschränkte Zeiten und übersprungene Tage; sie ist leichter als eine vollständige Entscheidung. Siehe Planung.

Virtuelle Bedingungen

Eine virtuelle Bedingung vergleicht Werte, die keine gespeicherten Felder sind, Daten, die mit dem Trigger ankamen oder die ein früherer Schritt erzeugt hat, adressiert mit {{ __data.… }}. Dies ist der Entscheidungstyp, den Sie in Workflows mit dynamischen Endpunkten verwenden. Da seine Einrichtung speziell ist, hat er eine eigene Seite: Virtuelle Bedingungen.

Jede Entscheidung muss ihre Zweige verbunden haben. Hängen Sie die Schritte, die bei Ja laufen sollen, an den Ja-Zweig und die Schritte für Nein an den Nein-Zweig. Ein Schritt, der an keinem der beiden Zweige hängt, läuft nie.

Listener als Tore mitten im Workflow

Ein Listener, der innerhalb eines Workflows platziert ist, pausiert seinen Zweig, bis ein externes Signal eintrifft. Zum Beispiel: eine E-Mail senden, dann warten, bis sie geöffnet wird, bevor es weitergeht. Wenn das Signal kommt, läuft der Zweig weiter und die Daten des Signals stehen den nachfolgenden Schritten zur Verfügung. Listener als Start eines Workflows werden in Trigger & Quellen behandelt.

Der Listener-Katalog

Die verfügbaren Listener, nach Bereich gruppiert, und wo jeder sinnvoll ist (am Start eines Workflows, mitten im Baum nach einem früheren Schritt oder beides):

Bereich	Listener	Wo er sitzen kann
E-Mail	Eine E-Mail wird geöffnet	Mitten im Baum, nach einem Schritt, der die E-Mail gesendet hat
	Ein Link in einer E-Mail wird geklickt	Mitten im Baum, nach einem Schritt, der die E-Mail gesendet hat
	Eine E-Mail wird beantwortet	Mitten im Baum
	Eine E-Mail wird zurückgewiesen oder schlägt fehl	Mitten im Baum
	Ein Anhang wird heruntergeladen	Mitten im Baum
Postfach	Eine E-Mail trifft in einem verbundenen Postfach ein	Start (ein __virtual-Workflow)
SMS / WhatsApp	Eine SMS- oder WhatsApp-Nachricht wird empfangen	Start
	Eine SMS- oder WhatsApp-Nachricht wird zugestellt	Start oder mitten im Baum
Formulare	Ein Formular wird abgeschickt	Start, siehe Formulare
Notizen & Aufgaben	Eine neue Aufgabe wird angelegt	Start
	Eine Aufgabe wird aktualisiert	Start
	Eine neue Notiz wird hinzugefügt	Start
	Ein neuer Kommentar wird zu einer Notiz hinzugefügt	Start
	Ein Nutzer wird in einer Notiz oder einem Kommentar erwähnt	Start
Seiten / Links	Eine getrackte Seite wird besucht	Start
Virtuelle Entität	Eine Web-Anfrage trifft einen dynamischen Endpunkt	Start eines __virtual-Workflows, siehe Dynamische Endpunkte

Einige Listener (insbesondere E-Mail geöffnet, Link geklickt und Anhang heruntergeladen) ergeben nur nach dem Senden einer E-Mail früher im selben Workflow Sinn, daher bietet der Builder sie nur als Schritte mitten im Baum an. Die übrigen können entweder einen Workflow starten oder innerhalb eines sitzen.

Jeder Listener schreibt die Daten seines Signals unter einem bestimmten Alias in den __data-Notizblock des Workflows, siehe die vollständige Payload-Referenz in Daten zwischen Schritten weitergeben.

Nächste Schritte

• Laufzeit, parallele Ausführung & der Baum: wie diese Schritte tatsächlich laufen.
• Daten zwischen Schritten weitergeben: jeden Schritt aus den vorherigen speisen.