Power Automate Genehmigungsworkflow: Mehrstufige Freigaben, Delegation und Eskalation

Wie wird ein Power Automate Genehmigungsworkflow aufgebaut, der mehrere Freigabestufen, Vertretungen und überfällige Entscheidungen zuverlässig behandelt? Der stabile Ansatz trennt den fachlichen Antrag, die einzelnen Genehmigungsstufen und jede konkrete Entscheidung voneinander. Power Automate steuert den Ablauf und sendet Approval-Anfragen; der dauerhafte Prozessstatus gehört zusätzlich in eine SharePoint-Liste, Dataverse-Tabelle oder ein anderes führendes System. Nur so bleibt er auswertbar, wenn eine Genehmigung abläuft, ein Flow fehlschlägt oder ein Verantwortlicher wechselt.

Ein mehrstufiger Workflow ist deshalb kein einzelner Block Start and wait for an approval. Er ist ein Zustandsmodell mit klaren Übergängen, Fristen, Idempotenz, Fehlerbehandlung und einem kontrollierten Rückfallweg. Wenn Genehmigungen Aufgaben erzeugen oder Statuswerte in SharePoint fortschreiben, sind die Muster aus SharePoint-Aufgaben mit Power Automate verbinden und Power Automate SharePoint Listen schreiben direkt anschlussfähig.

Wann ein Power Automate Genehmigungsworkflow nötig ist

Eine formale Genehmigung ist sinnvoll, wenn eine Entscheidung nachweisbar einer Person oder Rolle zugeordnet werden muss und der weitere Prozess von dieser Entscheidung abhängt. Beispiele sind Beschaffungen, Vertragsprüfungen, Publikationen, Investitionen oder Ausnahmen von Richtlinien.

Nicht jeder Abstimmungsprozess braucht ein Approval. Für unverbindliche Rückfragen, gemeinsame Bearbeitung oder reine Kenntnisnahme können Teams-Kommentare, Aufgaben oder Statusfelder geeigneter sein. Ein unnötig formaler Workflow erhöht Durchlaufzeit und Benachrichtigungsaufkommen.

Vier Grundvarianten

Mehrstufig bedeutet, dass nach einer Entscheidung eine weitere Stufe folgt. Parallel bedeutet, dass mehrere Genehmigungszweige gleichzeitig laufen. Beide Muster können kombiniert werden.

Das fachliche Datenmodell vor dem Flow definieren

Liste oder Tabelle Anträge

Der Antrag enthält die Geschäftsdaten und den Gesamtstatus:

• Antrags-ID,
• Antragstyp,
• Antragsteller,
• Kostenstelle oder Organisationseinheit,
• Betrag beziehungsweise Risikoklasse,
• eingereicht am,
• aktuelle Stufe,
• Gesamtstatus,
• aktuelle Verantwortungsrolle,
• finale Entscheidung,
• abgeschlossen am,
• letzte technische Verarbeitung,
• Korrelations-ID.

Eine Korrelations-ID verbindet Flow-Ausführungen, Approval-Datensätze, Protokolle und Benachrichtigungen. Sie sollte beim ersten Einreichen erzeugt und nicht bei jeder Wiederholung geändert werden.

Liste Genehmigungsstufen

Die Konfiguration der Stufen gehört nicht zwingend fest in den Flow. Eine separate Tabelle kann Regeln enthalten:

Feld: Prozessart

Beispiel: Beschaffung

Feld: Stufe

Beispiel: 20

Feld: Bedingung

Beispiel: Betrag über 10.000

Feld: Genehmigerquelle

Beispiel: Kostenstellenverantwortlicher

Feld: Modus

Beispiel: sequenziell

Feld: Antworttyp

Beispiel: Approve/Reject/Zurückgeben

Feld: Frist in Arbeitstagen

Beispiel: 3

Feld: Eskalationsrolle

Beispiel: Bereichsleitung

Feld: Vertretungsregel

Beispiel: zentrale Vertretungsliste

Konfiguration erhöht Wartbarkeit, darf aber nicht unkontrolliert von vielen Personen geändert werden. Änderungen müssen versioniert, getestet und zu einem definierten Zeitpunkt wirksam werden.

Liste Entscheidungen

Jede Anfrage und Antwort wird separat gespeichert:

• Antrags-ID,
• Stufen-ID,
• Approval-ID,
• vorgesehener Genehmiger,
• tatsächlich antwortende Person,
• Zuweisungszeitpunkt,
• Fälligkeit,
• Antwort,
• Kommentar,
• Antwortzeitpunkt,
• Delegationsgrund,
• Eskalationsstatus,
• technische Ausführungs-ID.

Dadurch bleibt die Historie erhalten, auch wenn der Gesamtstatus später geändert wird.

Einstufige und mehrstufige Freigaben: Aufbau und Datenfluss

Einstufiger Ablauf

1. Antrag wird validiert und auf Eingereicht gesetzt.
2. Flow ermittelt den Genehmiger aus einer kontrollierten Quelle.
3. Ein Entscheidungsdatensatz wird angelegt.
4. Approval wird gestartet.
5. Antwort wird normalisiert und im Entscheidungsdatensatz gespeichert.
6. Antrag erhält Genehmigt, Abgelehnt oder Zurückgegeben.
7. Nachgelagerte Aktionen starten nur anhand des gespeicherten Status.

Der letzte Punkt verhindert, dass eine E-Mail-Aktion oder ein externer Connector versehentlich als fachlicher Abschluss gilt.

Mehrstufiger Ablauf

Bei mehreren Stufen sollte der Flow nach jeder Entscheidung einen stabilen Zwischenzustand schreiben. Beispiel:

Eingereicht → Fachprüfung offen → Fachlich genehmigt → Budgetprüfung offen → Final genehmigt

So kann eine fehlgeschlagene Ausführung ab der letzten abgeschlossenen Stufe wiederaufgenommen werden. Wird alles in einer einzigen langen Ausführung gehalten, erschweren Timeouts, Änderungen und manuelle Korrekturen den Betrieb.

Regeln nie nur aus Anzeigenamen ableiten

Genehmiger sollten über stabile Identitäten oder Gruppen ermittelt werden. Anzeigenamen sind nicht eindeutig. E-Mail-Adressen können sich ändern. Für historische Nachweise empfiehlt sich eine Kombination aus Objekt-ID, zum Zeitpunkt der Zuweisung gespeicherter Adresse und lesbarem Namen.

Parallele und sequenzielle Genehmigungen richtig wählen

Sequenziell

Eine sequenzielle Freigabe passt, wenn eine Entscheidung die nächste fachlich vorbereitet oder wenn die nächste Rolle erst nach Zustimmung aktiv werden soll. Beispiele:

• Fachprüfung vor Budgetfreigabe,
• Datenschutzprüfung vor Veröffentlichung,
• lokale Genehmigung vor zentraler Genehmigung.

Vorteil ist der klare Verlauf. Nachteil ist die längere Gesamtdauer.

Parallel

Parallele Genehmigungen passen, wenn Rollen unabhängig voneinander prüfen können, etwa IT-Sicherheit, Datenschutz und Einkauf. In Power Automate können parallele Zweige oder eine Genehmigung an mehrere Personen eingesetzt werden.

Vorab muss die Entscheidungsregel feststehen:

• Müssen alle zustimmen?
• Reicht eine Zustimmung?
• Stoppt eine Ablehnung sofort alle anderen Zweige?
• Werden bereits abgegebene Antworten trotzdem gespeichert?
• Was passiert bei widersprüchlichen Antworten?

Zusammenführung nach parallelen Zweigen

Die Zusammenführung sollte nicht nur auf den technischen Status eines Zweigs reagieren. Schreiben Sie jede Teilentscheidung in die Entscheidungstabelle und berechnen Sie danach den Gesamtstatus. Eine mögliche Regel ist:

• mindestens eine Ablehnung → Gesamtstatus Abgelehnt,
• alle erforderlichen Zustimmungen vorhanden → Genehmigt,
• mindestens eine Antwort offen → In Prüfung,
• technische Störung → Klärung erforderlich.

Das ist nachvollziehbarer als verschachtelte Bedingungen über dynamische Flow-Ausgaben.

Delegation und Vertretung technisch umsetzen

Vertretung vor dem Start auflösen

Der robusteste Ansatz ermittelt vor der Approval-Erstellung, wer aktuell zuständig ist. Eine Vertretungsliste kann enthalten:

• Primärverantwortlicher,
• Vertretung,
• gültig von/bis,
• Prozessarten,
• maximale Entscheidungshöhe,
• Freigabestatus der Vertretung,
• letzte Prüfung.

Der Flow prüft Datum und Prozessart und weist die Genehmigung direkt der gültigen Person zu. Der Entscheidungsdatensatz speichert sowohl die ursprüngliche Rolle als auch die tatsächlich adressierte Person.

Reassignment nicht mit Vertretungskonzept verwechseln

Approvals können je nach Oberfläche und Einstellungen neu zugewiesen werden. Eine spontane Neuzuweisung ist jedoch kein vollständiges Vertretungsmodell. Sie beantwortet nicht automatisch, ob die Vertretung fachlich befugt ist, ob Limits gelten und wie die Änderung protokolliert wird.

Für komplexe Szenarien stellt Microsoft ein Business Approvals Kit mit erweiterten Approval-Mustern bereit. Dessen Delegationsfunktionen sind nicht identisch mit einem einfachen Standard-Approval und erfordern eine eigene Architektur- und Lizenzprüfung.

Abwesenheit als Datenquelle

Eine Kalenderabwesenheit kann ein Hinweis sein, ist aber nicht immer eine rechtssichere Vertretungsregel. Termine können privat, unvollständig oder nicht aktuell sein. Verwenden Sie Kalenderdaten nur, wenn die Organisation diesen Mechanismus ausdrücklich definiert hat. Der Beitrag Urlaubsstatus mit SharePoint und Power Automate prüfen erläutert das technische Muster und seine Grenzen.

Timeouts, Erinnerungen und Eskalation aufbauen

Cloud-Flow-Ausführungen haben dokumentierte Laufzeitgrenzen; Microsoft weist darauf hin, dass schwebende Schritte wie Approvals in diese Laufzeit einbezogen werden. Aktuell dokumentiert Microsoft für eine einzelne Cloud-Flow-Ausführung 30 Tage; danach laufen ausstehende Schritte wie Approvals aus. Ein Genehmigungsprozess sollte deshalb nicht unbegrenzt in einer wartenden Aktion hängen.

Zwei Betriebsmodelle

Kurzer Prozess: Start and wait for an approval wartet innerhalb derselben Ausführung. Das ist für überschaubare Fristen und geringe Komplexität geeignet.

Lang laufender Prozess: Approval wird erstellt, seine ID gespeichert und ein separater geplanter Prozess überwacht offene Entscheidungen. Das entkoppelt fachliche Wartezeit von einer einzelnen Flow-Ausführung und erleichtert Erinnerungen, Eskalation und Wiederaufnahme.

Fristen explizit speichern

Speichern Sie Fällig am im Entscheidungsdatensatz. Ein täglicher Überwachungsflow kann offene Entscheidungen in Stufen behandeln:

1. freundliche Erinnerung vor Fälligkeit,
2. Erinnerung am Fälligkeitstag,
3. Eskalation nach Überschreitung,
4. technische oder fachliche Übergabe nach maximaler Frist.

Verwenden Sie eine Spalte LetzteErinnerungsstufe, damit derselbe Hinweis nicht bei jedem Lauf erneut versendet wird. Zeitzone, Wochenenden und Feiertage müssen zur Prozessregel passen. „Drei Tage“ ist ohne Definition nicht eindeutig.

Eskalation ist eine Prozessentscheidung

Eine Eskalation kann informieren, neu zuweisen, eine alternative Rolle aktivieren oder den Antrag abbrechen. Diese Reaktion darf nicht vom Flow-Entwickler frei erfunden werden. Sie muss fachlich freigegeben sein.

Typische Fehlerbilder und Rückfallpfade

Approval hängt scheinbar dauerhaft

Ursachen: falsche Adresse, deaktiviertes Konto, fehlende Lizenz oder Berechtigung, Gastbenutzer mit eingeschränkter Oberfläche, ungültige Gruppe oder abgelaufene Flow-Ausführung.

Test: Approval-ID, Empfänger, Ausführungsstatus und Benachrichtigungsverlauf prüfen; mit einem Testkonto antworten.

Rückfall: offene Entscheidung kontrolliert stornieren oder als technisch fehlgeschlagen markieren, Empfänger korrigieren und eine neue Entscheidungsinstanz mit Referenz auf die alte erzeugen.

Derselbe Antrag wird doppelt gestartet

Ursachen: Trigger reagiert auf jede Änderung, Benutzer klickt mehrfach oder ein Retry erzeugt erneut eine Genehmigung.

Schutz: Statuswechsel als Triggerbedingung, Korrelations-ID, eindeutiger Schlüssel aus Antrag und Stufe sowie Prüfung auf bereits offene Entscheidungen.

Rückfall: doppelte Approval-Instanz kennzeichnen und schließen; fachlichen Datensatz nicht löschen.

Ablehnungspfad fehlt

Symptom: Der Flow endet nach einer Ablehnung technisch erfolgreich, der Antrag bleibt aber auf In Prüfung.

Schutz: Für jede mögliche Antwort einen expliziten Statusübergang definieren.

Rückfall: Korrekturflow oder kontrollierte manuelle Statuskorrektur mit Audit-Kommentar.

Benachrichtigungsflut

Ursache: Jede Änderung löst neue Mails aus; parallele Prüfer erhalten unnötige Zwischenmeldungen.

Schutz: Sammelbenachrichtigungen, klar definierte Ereignisse und gespeicherte Versandstufen.

Rückfall: Erinnerungsflow deaktivieren, offene Fälle exportieren und nach Korrektur gezielt neu starten.

Flow-Owner fällt aus

Ursache: Flow und Connections hängen an einer einzelnen Person.

Schutz: dokumentierte Co-Owner, geeignete Funktionsidentität, Lösungen, Umgebungsvariablen und Betriebsübergabe.

Rückfall: Connections kontrolliert ersetzen, Berechtigungen prüfen und mit Testantrag validieren, bevor offene Fälle weiterlaufen.

Testplan für mehrstufige Genehmigungen

Fachliche Pfade

• jede Stufe genehmigt,
• Ablehnung in jeder möglichen Stufe,
• Rückgabe zur Korrektur,
• Betrag oder Risiko unterhalb und oberhalb jeder Schwelle,
• parallele Zustimmung und widersprüchliche Antworten.

Identitäten und Vertretung

• Primärgenehmiger aktiv,
• Vertretung innerhalb und außerhalb ihres Gültigkeitszeitraums,
• deaktiviertes Konto,
• geänderte E-Mail-Adresse,
• Gruppe ohne Mitglieder,
• externer Gast, sofern vorgesehen.

Zeit und Eskalation

• Erinnerung vor Fälligkeit,
• Fälligkeit in verschiedener Zeitzone,
• Wochenende oder Feiertag,
• Eskalation,
• maximale Prozessdauer,
• spätere Antwort nach bereits erfolgter Eskalation.

Technische Störungen

• SharePoint vorübergehend nicht erreichbar,
• Approval-Aktion schlägt fehl,
• Benachrichtigung schlägt fehl,
• Flow wird während offener Fälle aktualisiert,
• Wiederholung einer fehlgeschlagenen Aktion,
• manueller Neustart mit derselben Korrelations-ID.

Die Abnahme sollte nicht nur prüfen, ob eine E-Mail ankommt. Entscheidend ist, ob Antrag, Entscheidung, Verantwortlicher, Frist und Verlauf im führenden System korrekt bleiben.

Betrieb, Monitoring und Änderungen

Ein produktiver Genehmigungsworkflow braucht mindestens:

• Verantwortliche für Fachprozess und Technik,
• Alarmierung bei fehlgeschlagenen Ausführungen,
• Übersicht offener und überfälliger Entscheidungen,
• Versionierung der Regeln,
• kontrollierte Änderungen in einer Testumgebung,
• dokumentierte Wiederanlaufprozedur,
• regelmäßige Prüfung von Gruppen, Vertretungen und Connections.

Allgemeine Grundmuster für Prozessautomatisierung beschreibt Prozesse mit Power Automate und SharePoint optimieren. Ein konkreter Compliance-Anwendungsfall findet sich in Richtlinien und Compliance-Dokumente automatisiert verteilen.

So bleibt der Genehmigungsworkflow auch bei parallelen Freigaben und Ausnahmen stabil

Ein stabiler Workflow speichert nicht nur das Endergebnis, sondern jede Stufe, Zuweisung, Frist und Entscheidung. Sequenzielle und parallele Freigaben werden anhand fachlicher Regeln gewählt, Vertretungen vor der Zuweisung geprüft und lange Wartezeiten durch einen überwachten Zustandsprozess entkoppelt. Mit eindeutigen Schlüsseln, expliziten Rückfallpfaden und Tests für Ausnahmen bleibt der Prozess auch dann nachvollziehbar, wenn Personen, Regeln oder technische Verbindungen wechseln.