Die digitale Fabrikhalle: Wie drei spezialisierte Power Automate Flows einen Prozess vollständig automatisieren

Wenn man zum ersten Mal mit Power Automate arbeitet, ist die Versuchung groß, alles in einen einzigen Flow zu packen. Ein Flow, der alles macht. Das klingt effizient, ist es aber nicht. Große, monolithische Flows sind schwer zu debuggen, schwer zu warten und schwer zu erweitern.

Für die Nutzerinventur habe ich mich bewusst für drei spezialisierte Flows entschieden. Jeder hat eine klare Verantwortung, ist unabhängig testbar und kann ohne Auswirkungen auf die anderen angepasst werden. Das ist keine Überarchitektur, das ist pragmatisches Handwerk.

Flow 1: Der Inventurtrigger

Dieser Flow ist der Startschuss. Er läuft zeitgesteuert und prüft, welche User eine fällige Inventur haben.

Der Aufbau im Detail

1. Recurrence-Trigger: Der Flow startet automatisch nach einem definierten Zeitplan. Kein Mensch muss ihn anstoßen.
2. SharePoint-Filter: Die Liste wird gefiltert: Status = Aktiv UND nächste_Inventur < heute. Nur diese User werden verarbeitet.
3. Status-Sicherung: Alle gefundenen User werden sofort auf „im Flow Prozess“ gesetzt. Das ist der Schutz gegen Doppelverarbeitung. Wenn der Flow beim nächsten Durchlauf startet, sind diese User nicht mehr im Filter.
4. Genehmigungsmail: Für jeden User wird eine Genehmigungsanfrage gesendet. Der User kann direkt in der Mail auf „Ja, Zugang wird benötigt“ oder „Nein, Zugang kann gelöscht werden“ klicken. Kein Login, kein Formular.
5. Parallelverarbeitung: Bis zu 50 Genehmigungsprozesse laufen gleichzeitig. Wenn einer abgeschlossen wird, rückt der nächste nach. Das verhindert, dass der Flow bei vielen Usern stundenlang läuft.
6. Timeout nach 20 Tagen: Wer nicht antwortet, wird nach 20 Tagen automatisch aus dem Prozess genommen.
7. Antwortauswertung: Ja bedeutet: Status zurück auf „Aktiv“, Inventurdatum neu setzen. Nein bedeutet: Löschkandidat-Flag setzen, Status auf „gelöscht“ vorbereiten.

Der Knackpunkt: Eigene Antwortoptionen in Genehmigungsmails

Standardmäßig bietet Power Automate nur „Genehmigen“ und „Ablehnen“ als Antwortoptionen. Für die Nutzerinventur wollte ich klarere, nutzerfreundlichere Texte. Das geht über den Genehmigungstyp „Benutzerdefinierte Antworten“.

Dort können beliebige Texte als Antwortoptionen definiert werden. Der Flow wertet dann aus, welche Option der User gewählt hat, und verzweigt entsprechend. Das klingt einfach, und ist es auch. Aber es ist gut versteckt. Der richtige Genehmigungstyp muss bewusst ausgewählt werden, er ist nicht der Standard.

Die Timeout-Entscheidung: Von 28 auf 20 Tage

Ursprünglich war ein Timeout von 28 Tagen geplant. Nach Überlegung wurde er auf 20 Tage reduziert. Der Grund: Nach dem Timeout kommt noch eine Erinnerungsmail mit 14 Tagen zusätzlicher Frist. Insgesamt hat ein User also 34 Tage Zeit zu antworten. Das ist mehr als ausreichend.

Kürzere Timeouts bedeuten schnellere Prozesse und weniger offene Genehmigungen, die im System hängen. Das ist eine bewusste Abwägung zwischen Nutzerfreundlichkeit und Prozesseffizienz.

Flow 2: Der Reminder-Flow

Der Reminder-Flow greift alle User auf, die den Inventurtrigger-Timeout erreicht haben. Er ist strukturell ähnlich aufgebaut wie der Inventurtrigger, hat aber eine andere Aufgabe.

Der Aufbau

• Recurrence-Trigger: Läuft zeitgesteuert, unabhängig vom Inventurtrigger
• Filter: Status = „im Flow Prozess“ UND Reminder noch nicht gesendet UND Endtermin < heute
• Status-Sicherung: Status auf „im Reminder Prozess“ setzen
• Erinnerungsmail senden mit neuem Endtermin von 14 Tagen
• Endtermin und Reminder-Status in der Liste aktualisieren
• Timeout-Überwachung: Wer nach 14 Tagen nicht antwortet, wird automatisch als Löschkandidat markiert
• Antwortauswertung: Ja bedeutet Inventurdatum neu setzen, Nein bedeutet Löschkandidat

Das Spam-Problem: Eine unerwartete Hürde

Die erste Version der Erinnerungsmail landete bei den Empfängern im Spam-Ordner. Der Betreff war zu generisch. Automatisch generierte Mails mit generischen Betreffs werden von Spam-Filtern häufig als verdächtig eingestuft.

Die Lösung war einfach: Einen spezifischen, klaren Betreff verwenden, der den Kontext sofort erklärt. Das Learning: Teste Flows immer mit echten Empfängern, bevor du sie produktiv schaltest. Was in deinem Postfach ankommt, muss nicht bei anderen ankommen.

Flow 3: Der Lösch-Flow

Der Lösch-Flow ist der letzte Schritt im Prozess. Er verarbeitet alle User, die als Löschkandidaten markiert wurden, und schließt den Inventurprozess für diese User ab.

Der Aufbau

• Recurrence-Trigger: Läuft zeitgesteuert
• Filter: Löschkandidat = Ja ODER (Reminder gesendet = ja UND Endtermin < heute)
• Status auf „im Löschprozess“ setzen
• Löschmail an den KeyUser senden (aktuell manuell eingetragen, zukünftig aus IT-Systemliste)
• Antwortmöglichkeiten: User gelöscht oder Ausnahmeregelung
• Wahr: Löschmail an den User senden, User aus der Inventurliste entfernen
• Falsch: Ausnahmeregelung, Status zurück auf „Aktiv“ setzen

Was noch fehlt und warum das in Ordnung ist

In der aktuellen Version wird der Systembetreuer nicht automatisch informiert, wer gelöscht wird. Die E-Mail-Adresse des KeyUsers ist manuell eingetragen, nicht automatisch aus einer IT-Systemliste gezogen. Das sind bekannte Einschränkungen, die für den MVP bewusst akzeptiert wurden.

Der Grund: Ein funktionierender MVP mit bekannten Einschränkungen ist wertvoller als ein perfektes System, das nie fertig wird. Die Erweiterungen sind dokumentiert und können in einer späteren Version umgesetzt werden.

Das berüchtigte For-Each-Problem

Power Automate hat eine Eigenheit, die jeden Entwickler früher oder später trifft: Es erstellt automatisch „Apply to each“-Schleifen, wenn es erkennt, dass ein Wert ein Array sein könnte. Das passiert auch dann, wenn man es nicht will.

Beim Lösch-Flow ist genau das passiert. Power Automate hat automatisch mehrere For-Each-Schleifen eingefügt, die den Flow falsch strukturiert haben. Der erste Test ist entsprechend schiefgelaufen.

Die Lösung: Den genauen Ausgabewert der vorherigen Aktion prüfen und sicherstellen, dass nur der einzelne Wert referenziert wird, nicht das gesamte Array. Nach dem ersten Test hat Power Automate die Schleifen nicht mehr eingefügt, obwohl sich an den Parametern nichts geändert hatte. Das Verhalten von Power Automate ist hier nicht immer vorhersehbar.

Das Learning: Wenn Power Automate automatisch eine Schleife einfügt, die du nicht erwartet hast, prüfe zuerst, welchen Wert du referenzierst. Oft ist es ein Array, wo du einen einzelnen Wert erwartest. Und teste jeden Flow nach jeder Änderung, nicht erst am Ende.

Weiterführende Artikel zur Nutzerinventur

Von der Zettelwirtschaft zum vollautomatischen System: Wie ich die Nutzerinventur in 8 Stunden neu erfunden habe
Das Fundament: Wie SharePoint-Liste und Power App das Rückgrat der Nutzerinventur bilden
Das Handwerk hinter dem Code: Warum Dokumentation der wahre Hebel für professionelles Citizen Development ist