Laufzeit, parallele Ausführung & der Baum

Dies ist die technischste Seite im Workflows-Bereich. Für einen einfachen Workflow brauchen Sie sie nicht, aber für einen schnellen, korrekten und stark ausgelasteten schon.

Der Baum

Ein Workflow ist ein Baum aus Schritten. Jeder Schritt (außer dem Trigger an der Wurzel) hat genau einen Elternschritt, und die Ausführung fließt vom Elternschritt hinunter zu seinen Kindern.

Zwei Verbindungsregeln:

Kinder einer Aktion laufen einfach nach ihr.
Kinder einer Entscheidung sind mit Ja oder Nein markiert. Die Engine folgt nur dem Zweig, der zum Ergebnis der Entscheidung passt. Ein Kind, das keinem Zweig zugeordnet ist, wird nie erreicht. Das ist die häufigste Ursache für die Frage „Warum ist mein Schritt nicht gelaufen?“: Er wurde nicht auf den Zweig gesetzt.

Der Baum hat auch Leitplanken: keine Schleifen (ein Schritt kann nicht zu sich selbst zurückführen), und der Builder hängt einen losen Schritt automatisch an den vorherigen an, statt ihn verwaist zu lassen.

Mehrere Schritte unter einem Elternschritt

Sie können mehrere Schritte direkt unter denselben Elternschritt hängen. Sie sind Geschwister. Die Engine führt sie nicht strikt nacheinander aus und wartet dazwischen. Sie verteilt sie gemeinsam, und sie können parallel laufen, siehe unten.

Mehrere Wurzeln

Ein Workflow kann mehr als einen Startschritt haben. Wenn die Quelle auslöst, starten alle Wurzeln parallel.

Wie ein Lauf abläuft

Wenn die Quelle eines Workflows auslöst, geht die Engine so vor:

Sie bildet den Stapel der Datensätze, die zum Trigger passten.
Sie durchläuft den Baum von oben. Für jeden Schritt ermittelt sie das Timing (jetzt ausführen, kurz warten oder für später einplanen), führt den Schritt aus und schreibt einen Logeintrag dafür.
Sie routet nach Ergebnis. Erfolg oder Fehlschlag einer Aktion und das Ja oder Nein einer Entscheidung bestimmen, welche Kinder als Nächstes kommen. Bei einer Entscheidung wird der Stapel der Datensätze in die aufgeteilt, die Ja ergaben, und die, die Nein ergaben, und jeder Zweig läuft mit seiner eigenen Menge weiter.
Sie wiederholt das entlang jedes Zweigs, bis jeder Pfad endet.

Jeder Schritt schreibt eine Logzeile, sodass Sie genau sehen, was passiert ist, siehe die Aktivitätslogs.

Async vs. Sync (im Hintergrund oder sofort)

Ein Workflow hat einen Ausführungsmodus, den Sie beim Anlegen wählen. Die beiden Einstellungen im Builder heißen Async und Sync:

	Async (Standard, läuft im Hintergrund)	Sync (läuft sofort, inline)
Wie Schritte laufen	Jeder Schritt wird an die Queue übergeben und von einem Worker aufgenommen	Jeder Schritt läuft inline, sofort, der Reihe nach
Gefühlte Geschwindigkeit	Nahezu in Echtzeit, hängt aber davon ab, wie ausgelastet die Queue ist	In Echtzeit, keine Wartezeit in der Queue
Am besten für	Fast alle CRM-Automatisierungen, skaliert und fängt Lastspitzen ab	Fälle, die sofort innerhalb einer einzelnen Interaktion abgeschlossen sein müssen (eine Aktion auf dem Bildschirm), und kurze Tests
Wenn ein Schritt fehlschlägt	Es wird protokolliert und der Lauf läuft weiter	Der Fehler erscheint sofort bei dem, was den Lauf gestartet hat

Nutzen Sie Async, sofern Sie keinen konkreten Grund dagegen haben. Es ist der Standard, weil es die Arbeit über mehrere Worker verteilt, Lastspitzen übersteht und den Rest des Systems reaktionsfähig hält. Der Sync-Modus ist für die schmale Menge von Fällen, die ein Ergebnis innerhalb einer Live-Interaktion brauchen.

Einige bestimmte Schritttypen laufen immer sofort, unabhängig vom Modus des Workflows, zum Beispiel eine Benachrichtigung auf dem Bildschirm, bei der „später“ keinen Sinn ergibt.

Wie Zweige parallel laufen

Das ist der Teil, der am häufigsten missverstanden wird, deshalb lohnt es sich, hier präzise zu sein.

Im Async-Modus übergibt die Engine, sobald sie an einen Punkt mit mehreren als Nächstes auszuführenden Schritten gelangt (Geschwisterschritte unter einem Elternschritt, mehrere Startwurzeln oder die beiden Zweige einer Entscheidung, in die jeweils Datensätze fließen), jeden davon als eigenen Job an die Queue. Der Pool aus Workern nimmt diese Jobs dann auf und führt sie nebenläufig aus.

Parallelität entsteht also an zwei Stellen:

Über Schritte hinweg: Unabhängige Zweige rücken gleichzeitig vor, auf verschiedenen Workern.
Über Datensätze hinweg: Ein Stapel aus vielen Datensätzen wird vom Worker-Pool gemeinsam verarbeitet, nicht strikt einer nach dem anderen.

Was das für Sie bedeutet:

Nehmen Sie nicht an, dass Geschwisterschritte in einer festen Reihenfolge fertig werden. Wenn Schritt B nach Schritt A passieren muss, hängen Sie B unter A, statt sie nebeneinander zu setzen und zu hoffen.
Machen Sie Schritte, die zusammen laufen könnten, dafür sicher. Wenn zwei Zweige beide dasselbe Feld berühren, entscheiden Sie bewusst, welcher gewinnen soll, oder bringen Sie sie in eine Reihenfolge.
Ein späterer Schritt, der die Ausgabe eines früheren Schritts braucht, muss im Baum ein Nachfolger davon sein, denn so werden auch die Daten weitergegeben (siehe Daten zwischen Schritten weitergeben).

Der Sync-Modus führt Schritte der Reihe nach aus, statt sie an Worker zu verteilen, daher gibt es keine Parallelität über Schritte hinweg. Ein weiterer Grund, warum er kurzen, geordneten und zwingend sofortigen Flows vorbehalten ist.

Timing der Schritte: jetzt, bald oder später

Jeder Schritt hat einen Trigger-Modus, der bestimmt, wann er läuft, sobald die Ausführung ihn erreicht:

Trigger-Modus	Verhalten
Sofort	Läuft, sobald der Schritt erreicht wird (der Standard).
Intervall	Eine festgelegte Anzahl von Minuten, Stunden oder Tagen ab dem Elternschritt warten, dann ausführen.
Datum	Zu einem bestimmten Datum und einer bestimmten Uhrzeit ausführen.

Die Engine handhabt das effizient mit einer 10-Sekunden-Schwelle:

Eine Wartezeit von 10 Sekunden oder weniger wird vor Ort gehalten. Die Engine pausiert nur kurz und führt den Schritt inline aus. Kein Umweg über die Queue.
Eine Wartezeit von mehr als 10 Sekunden (oder ein fester Termin in der Zukunft) wird geparkt: Der Schritt wird mit einem Trigger-Datum festgehalten und vom Scheduler aufgenommen, wenn seine Zeit gekommen ist. In der Zwischenzeit bleibt nichts offen. Der Worker, der den Schritt erreicht hat, wird sofort freigegeben.

Deshalb kostet ein Workflow mit Tausenden Datensätzen bei einer 7-Tage-Verzögerung während des Wartens fast nichts: Jeder geparkte Datensatz ist nur eine Logzeile mit einem künftigen Trigger-Datum. Ein separater Scheduler durchsucht in einem engen Zyklus nach fälligen Zeilen und verteilt sie.

Eingeschränkte Zeiten und übersprungene Tage

Ein Schritt kann auch auf ein Zeitfenster (mit Zeitzone) und auf bestimmte Wochentage eingeschränkt werden. Ein Schritt, der außerhalb seines Fensters fällig wird, bleibt in der Queue und wird ausgelöst, sobald das Fenster öffnet, nicht verworfen. Zeitfenster, die über Mitternacht reichen (z. B. 22:00 bis 06:00), werden korrekt behandelt. Die Konfiguration davon wird unter Scheduling behandelt.

Wie eine Entscheidung einen Stapel aufteilt

Wenn mehrere Datensätze gemeinsam in eine Entscheidung fließen, wertet die Engine die Bedingung für jeden einzelnen aus und teilt den Stapel in zwei: die Datensätze, die Ja ergaben, und die Datensätze, die Nein ergaben. Jeder Zweig läuft dann mit seiner eigenen Menge unabhängig weiter:

So kann ein einziger Workflow-Lauf viele Datensätze gleichzeitig über viele verschiedene Pfade führen. Die Logzeile jedes Schritts hält fest, wie viele Datensätze ihn durchlaufen haben und was passiert ist, sodass selbst eine komplexe Aufteilung über die Logs-Ansicht nachvollziehbar ist.

Warum ein stark ausgelasteter Workflow gesund bleibt

Der Async-Modus plus ein Worker-Pool bedeutet, dass Tausende Datensätze unterwegs sein können, ohne die App zu blockieren.
Geplante Schritte „warten“ nicht, indem sie Ressourcen belegen. Sie werden mit einem Trigger-Datum geparkt und pünktlich fortgesetzt.
Workflows aus Listen- und Zeitplanquellen werden durch ein stündliches Limit getaktet, sodass eine riesige Population verteilt wird, statt alles auf einmal abzuladen (siehe Throttling). Workflows aus Datensatzereignissen und Listener werden nicht getaktet. Sie reagieren sofort, weil sie von einzelnen Ereignissen statt von Massenpopulationen angetrieben werden.

Nächste Schritte

Daten zwischen Schritten weitergeben: wie Daten den Baum hinunterfließen.
Scheduling, Testen & Fehlerbehebung: Verzögerungen, Limits, Logs und Probleme beheben.