Modularisierung: Denken in Bausteinen statt Monolithen

Das Problem: Du hast den Genehmigungsprozess in fünf verschiedenen Flows eingebaut. Dann ändert sich eine Regel, und du musst fünf Flows anfassen. Einer davon geht kaputt. Niemand merkt es sofort. Kunden bekommen falsche Antworten.

---

Was ist Modularisierung?

In der klassischen Programmierung schreibt man Funktionen: wiederverwendbare Codeblöcke mit einem klaren Zweck. In Power Automate heißt das Äquivalent Child Flow.

Modularisierung ist das Prinzip, komplexe Abläufe in kleinere, eigenständige Funktionsbausteine zu zerlegen, die unabhängig entwickelt und wiederverwendet werden können.

Statt für jeden Prozess einen vollständigen Flow zu bauen, werden wiederkehrende Teilprozesse einmal gebaut, und von überall aufgerufen.

---

Warum das entscheidend ist: 7 Gründe für Child Flows

#	Vorteil	Warum das wichtig ist
1	Performance	Große Flows werden langsamer; parallele Child Flows vermeiden Engpässe
2	Debugging	Fehler sind leichter isolierbar, jeder Teil kann einzeln getestet werden
3	Weniger Berechtigungen	Child Flows können zentral mit Run-only-Rechten konfiguriert werden
4	Bessere Fehlermeldungen	Fehler lassen sich gezielter erfassen und behandeln
5	Detailliertes Error-Handling	Teilbereiche können einzeln überwacht werden
6	Weniger Verschachtelung	Power Automate hat ein Limit von 8 Nesting-Stufen, Child Flows helfen
7	Vereinfachung	Kleine Flows sind verständlicher, dokumentierbarer, wartbarer

---

Das Architekturmuster: Mehrere Flows, ein Modul

graph LR
 T1[" Trigger A\nForms"] --> F1["Flow A"]
 T2[" Trigger B\nSharePoint"] --> F2["Flow B"]
 T3[" Trigger C\nButton"] --> F3["Flow C"]

 F1 --> I[" Input"]
 F2 --> I
 F3 --> I

 I --> M[" Child Flow\n(Modularer Teilprozess)"]
 M --> O[" Output"]

 style T1 fill:#dbeafe,stroke:#3b82f6
 style T2 fill:#dbeafe,stroke:#3b82f6
 style T3 fill:#dbeafe,stroke:#3b82f6
 style M fill:#fef3c7,stroke:#f59e0b
 style I fill:#f3e8ff,stroke:#a855f7
 style O fill:#dcfce7,stroke:#22c55e

Mehrere Flows teilen sich denselben wiederverwendbaren Child Flow, mit klar definierter Schnittstelle.

---

Schnittstellen sauber definieren

Ein Child Flow ist so gut wie seine Schnittstelle (Interface). Definiere vor dem Bau immer zuerst:

Schnittstelle eines Child Flows
┌─────────────────────────────────────────────┐
│ INPUT │
│ ├─ Antragsteller (Text, Pflicht) │
│ ├─ Betrag (Zahl, Pflicht) │
│ └─ Kategorie (Text, optional) │
│ │
│ VERARBEITUNG │
│ └─ Genehmigungslogik, Prüfungen, Routing │
│ │
│ OUTPUT │
│ ├─ Status: "Success" | "Error" │
│ ├─ Message: Beschreibung des Ergebnisses │
│ └─ Data: Ergebnisobjekt (optional) │
└─────────────────────────────────────────────┘

Diese drei Output-Felder geben dem aufrufenden Flow immer genug Kontext, um zu wissen, was passiert ist.

---

Namenskonventionen, ohne die wird’s chaotisch

Eine Flow-Bibliothek ohne Konventionen wird unübersichtlich. Empfohlene Struktur:

[Team/Modul]_[Funktion]_[Version]

Beispiele:

• HR_GenehmigeUrlaub_v2
• Shared_SendeBenachrichtigung_v1
• Finance_PruefeBestellFreigabe_v1

Damit ist auf den ersten Blick klar:

• Wer ist verantwortlich?
• Was tut der Flow?
• Welche Version ist aktiv?

Versionierung ist in Low-Code besonders wichtig: Eine Änderung an einem zentralen Child Flow beeinflusst sofort alle aufrufenden Flows. Ohne Versionierung kann eine kleine Anpassung kaskadierende Ausfälle verursachen.

---

Lösungsarchitektur in Power Platform

In Power Platform werden Flows in Solutions organisiert. Für modulare Architekturen empfiehlt sich:

Solution	Inhalt
Shared Components	Alle wiederverwendbaren Child Flows, Bibliotheks-Module
Domain Solutions	Eine Solution pro Fachbereich (HR, Finance, IT)
Core Data	Dataverse-Tabellen, Environment Variables, Konfigurationsdaten

---

Praktisches Beispiel: Genehmigungsprozess

Ohne Modularisierung:

• Urlaubsantrag-Flow enthält Genehmigungslogik (200 Schritte)
• Investitionsanfrage-Flow enthält dieselbe Logik (erneut 200 Schritte)
• Reisekostenflow enthält sie nochmal
• Eine Regeländerung → 3 Flows anfassen → Garantiert mindestens ein Bug

Mit Modularisierung:

• Child Flow Shared_GenehmigeProzess_v1 enthält die Logik (einmal, gut getestet)
• Urlaubsantrag ruft ihn auf → fertig
• Investitionsanfrage ruft ihn auf → fertig
• Eine Regeländerung → 1 Flow anfassen → alle profitieren sofort

---

Fazit: Kleine Module, große Wirkung

Modularisierung ist kein technischer Luxus, es ist das Fundament wartbarer Low-Code-Lösungen.

Frage dich bei jedem neuen Flow: Gibt es Teile davon, die auch woanders gebraucht werden? Wenn ja: Bau ein Modul. Einmal. Richtig.

---