Child Flows in Power Automate: Prozesse modular aufbauen

Wie du mit Child Flows große Power-Automate-Prozesse in wiederverwendbare Teilschritte zerlegst und einfacher wartest.

Wer in Power Automate einen Prozess mit Dutzenden oder Hunderten Aktionen in einen einzigen Flow packt, merkt irgendwann, wie unübersichtlich das wird: Jede Änderung erfordert langes Scrollen, Fehler sind schwer zu lokalisieren, und ein Teilschritt, den du eigentlich an mehreren Stellen brauchst, existiert plötzlich dreimal in leicht unterschiedlichen Varianten. Child Flows lösen genau dieses Problem. Ein übergeordneter Flow (Parent Flow) ruft dabei einen oder mehrere untergeordnete Flows (Child Flows) auf, übergibt ihnen Eingaben und verarbeitet anschließend deren Rückgabewerte weiter, so wie eine Funktion in klassischem Code aus einem größeren Programm heraus aufgerufen wird.

Für Unternehmen, die Power Automate produktiv einsetzen, ist dieses Muster besonders dann relevant, wenn dieselbe Logik in mehreren Prozessen vorkommt, etwa das Ermitteln von Genehmigern, das Formatieren von Beträgen oder die Fehlerprotokollierung. Statt diese Logik in jedem Flow neu zu bauen, entsteht sie einmal als Child Flow und wird von allen passenden Parent Flows aufgerufen. Ändert sich die Logik, reicht eine einzige Anpassung an einer Stelle.

Was ist ein Child Flow?

Ein Child Flow ist ein ganz normaler Cloud Flow mit einer Besonderheit: Er startet nicht über einen klassischen Trigger wie einen Zeitplan oder ein neues Element in einer Liste, sondern wird direkt von einem anderen Flow gestartet. Microsoft beschreibt in der offiziellen Dokumentation Untergeordnete Flows erstellen, dass dafür eine Lösung mit mindestens zwei Flows nötig ist:

  • der Child Flow, verschachtelt im Parent Flow, mit den kleineren Aufgaben, die tatsächlich ausgeführt werden sollen
  • der Parent Flow, der einen beliebigen Trigger haben kann und den Child Flow an der passenden Stelle aufruft

Ein Parent Flow kann dabei mehrere unterschiedliche Child Flows enthalten, je nachdem, welche Teilaufgabe gerade dran ist. Wichtig ist, dass Parent und Child Flow direkt in derselben Lösung angelegt werden, denn nur so verknüpft Power Automate die beiden beim späteren Export und Import automatisch, ohne dass URLs manuell nachgepflegt werden müssen.

Warum sich die Modularisierung lohnt

Microsoft fasst die Vorteile in den Richtlinien zu wiederverwendbarem Code mit untergeordneten Flows zusammen, und in der Praxis zeigen sich diese Vorteile schnell:

  • Modularität: Wiederverwendbare Bausteine lassen sich in verschiedene Prozesse einbauen, ohne dass du Logik kopierst.
  • Wartbarkeit: Kleine, fokussierte Flows sind leichter zu lesen, und ein Fehler lässt sich gezielt in genau dem Baustein suchen, der ihn verursacht.
  • Skalierbarkeit: Neue Anforderungen landen als Anpassung an einem einzelnen Child Flow, statt den gesamten Prozess umzubauen.
  • Präzise Kontrolle: Über klar definierte Eingaben und Ausgaben steuerst du genau, welche Daten zwischen Parent und Child Flow fließen.
  • Zusammenarbeit im Team: Mehrere Personen können gleichzeitig an unterschiedlichen Child Flows arbeiten, ohne sich im selben riesigen Flow gegenseitig im Weg zu stehen.

Jeder Child Flow wird damit zu einem digitalen Mitarbeiter mit einer klar umrissenen Zuständigkeit, der zuverlässig genau eine Aufgabe erledigt und sich bei Bedarf einzeln testen, austauschen oder erweitern lässt.

Schritt für Schritt: Einen Child Flow erstellen

Schritt 1: Lösung und Direkt-Flow anlegen

Öffne in Power Automate eine bestehende Lösung oder lege eine neue an. Erstelle darin über Neu > Automation > Cloud-Flow > Direkt einen neuen Flow und wähle als Trigger Einen Flow manuell auslösen. Nur Flows mit diesem Trigger, dem Power-Apps-Trigger oder dem HTTP-Anforderungstrigger lassen sich später als Child Flow aufrufen.

Schritt 2: Eingaben definieren

Über Eingabe hinzufügen legst du fest, welche Werte der Parent Flow an den Child Flow übergeben soll, zum Beispiel einen Kontaktnamen oder eine Bestellnummer. Diese Eingaben erscheinen später im Parent Flow als dynamische Felder, sobald du den Child Flow dort auswählst.

Schritt 3: Logik bauen und Ergebnis zurückgeben

Baue innerhalb des Child Flows die eigentliche Aufgabe, egal ob das ein Datensatz in Dataverse, eine Berechnung oder ein Abgleich mit einer SharePoint-Liste ist. Am Ende gibst du das Ergebnis über die Aktion Antworten Sie auf eine Power App oder einen Flow beziehungsweise, im Premium-Connector, über Antwort zurück an den Parent Flow. Auch hier lassen sich beliebig viele Ausgabewerte definieren.

Schritt 4: Verbindungen einbetten

Verwendet der Child Flow andere Connectoren als eingebaute Aktionen oder Dataverse, musst du auf der Eigenschaftenseite unter Nur ausführende Benutzer für jede Verbindung Diese Verbindung verwenden statt Bereitgestellt von Nur-Benutzer-ausführen auswählen. Ohne diesen Schritt bricht der Aufruf mit einer Fehlermeldung ab, weil Child Flows ausschließlich eingebettete Verbindungen unterstützen und aktuell keine Verbindungen vom Parent Flow übernehmen können.

Den Parent Flow anbinden

Im Parent Flow fügst du an der gewünschten Stelle die Aktion Einen untergeordneten Flow ausführen aus dem Connector Flows hinzu und wählst den zuvor erstellten Child Flow aus. Angezeigt werden dabei nur Flows, auf die du Zugriff hast und die sich in derselben Lösung befinden. Nach der Auswahl erscheinen die im Child Flow definierten Eingabefelder, und nach dem Aufruf stehen die Ausgaben als dynamischer Inhalt für die folgenden Schritte zur Verfügung. Der Parent Flow wartet dabei auf den Abschluss des Child Flows, und zwar für die volle Laufzeit des Flows, also ein Jahr bei eingebauten Verbindungen und Dataverse oder 30 Tage bei allen anderen Connectoren.

Praxisbeispiel: Genehmiger aus SharePoint-Gruppen ermitteln

Ein Beispiel aus der Microsoft-Dokumentation zeigt das Muster gut: Ein Unternehmen benötigt für Projektvorschläge, Urlaubsanträge und Spesenabrechnungen jeweils Genehmigungen, wobei die zuständigen Personen in unterschiedlichen SharePoint-Gruppen gepflegt sind. Statt die Abfrage der jeweiligen Gruppe in drei separaten Flows nachzubauen, entsteht ein einziger Child Flow, der die passende SharePoint-Gruppe abfragt und die Liste der Genehmiger zurückgibt. Der Parent Flow für Projektvorschläge, der für Urlaubsanträge und der für Spesenabrechnungen rufen anschließend alle denselben Child Flow auf und übergeben nur, welche Gruppe jeweils gemeint ist. Ändert sich später die Struktur der SharePoint-Gruppen, passt du ausschließlich den Child Flow an, alle drei Prozesse profitieren automatisch davon.

Grenzen und Stolperfallen

Child Flows sind kein Selbstläufer und bringen ein paar feste Regeln mit, die du kennen solltest, bevor du größere Prozesse darauf aufbaust:

  • Parent und Child Flow müssen direkt in derselben Lösung erstellt werden. Importierst du einen bestehenden Flow nachträglich in eine Lösung, kann die Verknüpfung laut Microsoft zu unerwarteten Ergebnissen führen.
  • Verbindungen lassen sich aktuell nicht vom Parent an den Child Flow durchreichen, jede Verbindung im Child Flow muss dort eingebettet sein.
  • Ein Child Flow benötigt zwingend einen manuellen, Power-Apps- oder HTTP-Anforderungstrigger, andere Trigger stehen für diesen Zweck nicht zur Verfügung.
  • Bei sehr vielen Child Flows über mehrere Lösungen hinweg lohnt sich zusätzlich ein Blick auf die Lizenzierung, etwa auf Flow-Gruppen, mit denen sich eine Process-Lizenz über mehrere Flows und ihre Child-Flow-Ausführungen teilen lässt.

Du behältst dabei die Kontrolle darüber, wie granular du zerlegst: Nicht jeder Drei-Schritte-Vorgang braucht einen eigenen Child Flow, aber sobald eine Aufgabe an mehr als einer Stelle auftaucht oder ein Flow unübersichtlich wird, zahlt sich die Aufteilung schnell aus. Wer die Modularisierung bestehender Power-Automate-Prozesse mit klarer Struktur und sauberer Lösungsverwaltung umsetzen möchte, findet dabei Unterstützung in der Power-Automate-Beratung von NordFlux.

Häufige Fragen

Was ist der Unterschied zwischen einem Parent Flow und einem Child Flow?

Der Parent Flow kann jeden beliebigen Trigger haben und steuert den Gesamtprozess. Der Child Flow übernimmt eine einzelne, klar abgegrenzte Teilaufgabe, empfängt dafür Eingaben vom Parent Flow und gibt am Ende ein Ergebnis zurück, ähnlich einer Funktion in einem Programm.

Welche Trigger kann ein Child Flow verwenden?

Nur drei Trigger eignen sich für Child Flows: Einen Flow manuell auslösen, der Power-Apps-Trigger und der Trigger für eingehende HTTP-Anforderungen im Premium-Connector. Ein Recurrence- oder ein SharePoint-Trigger funktioniert für diesen Zweck nicht.

Kann ich eine bestehende Verbindung vom Parent Flow im Child Flow weiterverwenden?

Nein, aktuell lassen sich Verbindungen nicht vom Parent an den Child Flow übergeben. Jeder Connector, der im Child Flow verwendet wird, muss dort über die Einstellung für Nur-Benutzer-ausführen als eingebettete Verbindung hinterlegt sein.

Wie lange wartet der Parent Flow auf die Antwort des Child Flows?

Der Parent Flow pausiert, bis der Child Flow abgeschlossen ist, maximal für die Lebensdauer des Flows. Das sind ein Jahr bei Flows mit eingebauten Verbindungen und Dataverse und 30 Tage bei allen anderen Connectoren.

Müssen Parent Flow und Child Flow in derselben Lösung liegen?

Ja, Microsoft empfiehlt ausdrücklich, beide direkt in derselben Lösung anzulegen. Nur so werden sie beim Export in eine andere Umgebung automatisch korrekt miteinander verknüpft, ohne dass URLs manuell angepasst werden müssen.

Quellen: Microsoft Learn – Untergeordnete Flows erstellen, Microsoft Learn – Wiederverwendbaren Code für untergeordnete Flows erstellen

Über NordFlux

NordFlux UG (haftungsbeschränkt)

NordFlux baut Organisationen digitale Mitarbeiter: Automatisierungen und KI-Agenten, die wiederkehrende Arbeit abnehmen. Sie behalten die Kontrolle.

Mehr über uns
Kostenlose Erstanalyse

Konkrete Fragen zu Automatisierung oder KI?

In der kostenlosen Erstanalyse besprechen wir Ihren Fall direkt. Unverbindlich.