Sub-Prozess (flow.sub-process)
Startet einen anderen Flow als Unterprozess.
Wofür Sie diesen Baustein nutzen
In der Praxis entstehen in Schulen immer wieder Abläufe, die sich in mehreren Haupt-Flows wiederholen. Die Benachrichtigung der Erziehungsberechtigten, das Erstellen eines Protokolleintrags oder das Weiterleiten einer Meldung an das Sekretariat folgen fast immer demselben Muster — unabhängig davon, welcher übergeordnete Prozess sie auslöst.
Ohne den Baustein Sub-Prozess müssten Sie diese Teilkette in jedem einzelnen Flow neu abbilden. Änderungen an der Benachrichtigungslogik würden bedeuten, dass Sie jeden dieser Flows öffnen und einzeln anpassen müssten — was fehleranfällig ist und Zeit kostet.
Mit dem Baustein Sub-Prozess lagern Sie eine solche Teilkette einmalig in einen eigenständigen Flow aus. Dieser Hilfs-Flow — der Unterprozess — wird dann aus Ihren Haupt-Flows heraus aufgerufen, wann immer er gebraucht wird. Änderungen an der Logik nehmen Sie nur noch an einer einzigen Stelle vor.
Der Baustein erscheint in der Farbe Violett und ist damit im Flow-Designer auf den ersten Blick von anderen Aktionsbausteinen unterscheidbar.
Tipp
Denken Sie den Unterprozess als eine Art Vorlage für einen Teilablauf: einmal sorgfältig bauen, beliebig oft wiederverwenden. Je klarer der Unterprozess benannt und dokumentiert ist, desto leichter finden andere Administrierende ihn wieder.
Die Einstellungen im Detail
| Feld | Pflicht | Was es bewirkt |
|---|---|---|
Template-ID (templateId) | Ja | Die ID des Flows, der als Unterprozess gestartet werden soll. |
Input-Daten (JSON) (inputData) | Nein | Daten, die dem Unterprozess als Variablen mitgegeben werden. Unterstützt ${data.X}-Platzhalter aus dem aufrufenden Flow. |
Auf Beendigung warten (awaitCompletion) | Nein | Steuert, ob der Haupt-Flow anhält, bis der Unterprozess beendet ist. Werte: Ja oder Nein. |
Template-ID (templateId)
Dies ist die einzige Pflichtangabe. Sie geben hier die interne ID des Flows ein, der als Unterprozess ausgeführt werden soll. Die ID finden Sie in der Detailansicht des jeweiligen Flows im Flow-Designer — sie wird in der Adresszeile oder im Informationsbereich des Flows angezeigt.
Achten Sie darauf, die ID des richtigen Mandanten-Flows zu verwenden. Flows aus anderen Schulen oder Mandanten sind nicht aufrufbar.
Input-Daten (JSON) (inputData)
Über dieses Feld übergeben Sie dem Unterprozess Informationen, die er für seine Ausführung benötigt. Die Daten werden als JSON-Objekt formuliert. Sie können dabei Platzhalter aus dem aufrufenden Flow einsetzen, zum Beispiel:
{
"empfaengerId": "${data.schueler.id}",
"anlass": "${data.ereignis.bezeichnung}"
}Im Unterprozess stehen diese Werte dann als Variablen zur Verfügung. Wenn Sie keine Daten übergeben möchten, lassen Sie das Feld leer.
Auf Beendigung warten (awaitCompletion)
Diese Einstellung beeinflusst, ob der aufrufende Haupt-Flow nach dem Start des Unterprozesses weiterläuft oder zunächst anhält.
Hinweis zur aktuellen Umsetzung
Das Verhalten von "Auf Beendigung warten" ist derzeit ein Best-Effort-Mechanismus. Besteht der Unterprozess ausschließlich aus Sofort-Schritten — also Bausteinen wie E-Mail, Nachricht oder Daten setzen, die keine menschliche Eingabe erfordern — läuft er synchron durch und der Haupt-Flow wartet tatsächlich auf das Ergebnis.
Enthält der Unterprozess hingegen Bausteine, die auf menschliche Eingaben warten, zum Beispiel eine Genehmigung oder ein ausgefülltes Formular, läuft er als eigenständiger Durchlauf weiter. Der Haupt-Flow setzt seinen Weg in diesem Fall fort, ohne auf den Abschluss des Unterprozesses zu warten. Ein echtes übergreifendes Warten — also das zuverlässige Blockieren des Haupt-Flows bis zur Beendigung beliebiger Unterprozesse — ist als geplante Folgearbeit vorgesehen und noch nicht verfügbar.
Planen Sie Ihre Flows entsprechend: Für kritische Abhängigkeiten zwischen Haupt- und Unterprozess empfiehlt sich derzeit, den betreffenden Inhalt direkt in den Haupt-Flow zu integrieren.
Variablen / Platzhalter
Im Feld "Input-Daten (JSON)" können Sie alle Variablen verwenden, die im aufrufenden Flow zum Zeitpunkt des Bausteins verfügbar sind. Die Syntax folgt dem üblichen Muster ${data.X}, wobei X für den Pfad zur jeweiligen Variable steht.
Beispiele:
| Platzhalter | Bedeutung |
|---|---|
${data.kontakt.name} | Name des aktuellen Kontakts im Haupt-Flow |
${data.raum.bezeichnung} | Bezeichnung eines Raums aus dem aufrufenden Kontext |
${data.formular.antwortA} | Wert aus einem vorgelagerten Formularbaustein |
Die übergebenen Daten sind im Unterprozess als Eingabevariablen verfügbar und können dort mit denselben ${data.X}-Platzhaltern in weiteren Bausteinen verwendet werden.
Was dabei herauskommt
Wenn der Baustein erfolgreich ausgeführt wird, stellt er dem aufrufenden Flow zwei Ausgabewerte zur Verfügung:
| Variable | Inhalt |
|---|---|
childInstanceId | Die interne ID des gestarteten Unterprozess-Durchlaufs. Damit lässt sich der Durchlauf in der Übersicht nachverfolgen. |
childStatus | Der Status des Unterprozesses zum Zeitpunkt der Rückgabe. Bei synchroner Ausführung ist das in der Regel completed; bei asynchroner Ausführung typischerweise running. |
Diese Variablen können in nachfolgenden Bausteinen des Haupt-Flows per ${data.childInstanceId} beziehungsweise ${data.childStatus} verwendet werden — zum Beispiel, um den Status in einem Protokolleintrag zu dokumentieren.
Wenn etwas schiefgeht
Die Template-ID ist leer oder ungültig
Wenn das Feld "Template-ID" leer gelassen oder eine nicht existierende ID eingetragen wurde, bricht der Flow-Durchlauf an diesem Baustein mit einem Fehler ab. Prüfen Sie, ob die ID korrekt aus dem Ziel-Flow übertragen wurde und ob der Ziel-Flow noch aktiv und nicht archiviert ist.
Kein Unterprozess-Läufer verfügbar
Intern wird jeder Unterprozess von einem eigenen Ausführungskontext übernommen. Wenn zum Startzeitpunkt kein Läufer verfügbar ist — etwa weil das System kurzfristig ausgelastet ist — schlägt der Baustein fehl. In der Regel genügt es, den Durchlauf nach kurzer Zeit manuell neu zu starten. Sollte das Problem dauerhaft auftreten, wenden Sie sich an die Systemadministration.
Maximale Verschachtelungstiefe überschritten
Flows dürfen nicht beliebig tief ineinander verschachtelt werden. Wenn ein Unterprozess selbst weitere Unterprozesse aufruft, wird eine interne Tiefengrenze geprüft. Wird sie überschritten, bricht der Durchlauf mit einem entsprechenden Fehler ab. Überprüfen Sie in diesem Fall, ob die Verschachtelung tatsächlich notwendig ist, oder ob sich die Logik durch eine flachere Struktur abbilden lässt.
Hinweis
Vermeiden Sie es, einen Flow sich selbst als Unterprozess aufrufen zu lassen — weder direkt noch über Zwischenschritte. Auch wenn die Tiefengrenze dies technisch irgendwann unterbricht, führt eine solche Konstruktion zu schwer nachvollziehbarem Verhalten und sollte grundsätzlich vermieden werden.
Beispiel
Szenario: Wiederkehrende Benachrichtigungskette zentral verwalten
Eine Schule hat mehrere Workflows, bei denen Erziehungsberechtigte benachrichtigt werden müssen: bei Fehlzeiten, bei einer Versetzungsgefährdung und bei einem Elternabend. Die Benachrichtigungslogik — Nachricht formulieren, Kontaktdaten auflösen, Matrix-Nachricht versenden, Protokolleintrag erstellen — ist dabei immer gleich.
Anstatt diese vier Schritte in jeden einzelnen der drei Haupt-Flows zu kopieren, legt die Schuladministratorin einen eigenständigen Flow mit dem Namen "Elternteil benachrichtigen" an. Dieser Unterprozess erwartet als Eingabe die Elternteile-ID und den Benachrichtigungstext.
In jedem der drei Haupt-Flows steht nun an der entsprechenden Stelle ein Sub-Prozess-Baustein mit der ID des "Elternteil benachrichtigen"-Flows. Die Input-Daten werden aus dem jeweiligen Kontext des Haupt-Flows befüllt:
{
"elternteilId": "${data.schueler.erziehungsberechtigteId}",
"text": "Ihr Kind hat heute unentschuldigt gefehlt."
}Wenn sich künftig die Benachrichtigungslogik ändert — etwa weil ein zusätzlicher Protokollschritt hinzukommt — öffnet die Administratorin nur den einen Unterprozess und passt ihn an. Alle drei Haupt-Flows profitieren sofort von der Änderung.