Fehlerbehandlung und Retry-Design in Power Automate — Verhindern, dass ein Flow einfach stehenbleibt, ohne dass es jemand merkt

„Der Aggregations-Flow, der jeden Morgen lief, stand in Wirklichkeit schon seit letzter Woche still.“ „Der Flow zur Auftragsregistrierung hat dieselben Daten zweimal verarbeitet, und im Verzeichnis entstanden doppelte Zeilen.“ Solche Anfragen erreichen uns ständig, von Unternehmen, die einen Power-Automate-Flow gebaut und in Betrieb genommen haben. Der Bau war einfach — aber niemand hat bemerkt, als er stehen blieb.

Solange man nur den Erfolgsfall durchspielt, läuft ein Power-Automate-Flow stundenlang ohne Zwischenfall. Doch die Dienste, mit denen er verbunden ist, fallen zeitweise aus, Authentifizierungen laufen ab, und unerwartete Daten tauchen früher oder später garantiert auf. Ein Flow, der nicht dafür entworfen wurde, „was bei einem Fehlschlag passiert“, häuft still Fehlschläge an und wird im schlimmsten Fall nach 14 Tagen automatisch abgeschaltet¹. Dieser Artikel legt Entwurfsmuster für eine produktionstaugliche Fehlerbehandlung dar: die Klassifizierung von Flow-Fehlschlägen, die genaue Spezifikation des Standard-Retry, ein aus Scopes aufgebautes Try-Catch-Finally-Muster, Mechanismen zum Bemerken von Fehlern sowie erneute Ausführung und Idempotenz. Die Wahl zwischen den Gesamtbausteinen von Power Automate und der Fehlerbehandlung auf der Seite der UI-Automatisierung (Desktop-Flows) wird in Geschäftsprozesse mit Power Automate automatisieren — Cloud-Flows, Desktop-Flows und robuste Fehlerbehandlung behandelt; dieser Artikel konzentriert sich daher auf eine Vertiefung der Cloud-Flows.

1. Das Fazit zuerst

• Denken Sie sich Fehlschläge in vier Kategorien: vorübergehende Störungen, datenbedingte Fehler, abgelaufene Berechtigungen/Authentifizierung und Spezifikationsänderungen. Der Standard-Retry löst nur die erste davon; die übrigen drei benötigen einen Mechanismus zur Erkennung und Korrektur².
• Die Standard-Retry-Richtlinie greift nur, wenn eine Anfrage in ein Timeout läuft oder mit einer Antwort 408, 429 oder 5xx fehlschlägt. Standardmäßig wird exponentiell zurückgesetzt (Backoff), und die Anzahl beträgt je nach Lizenzstufe (Leistungsprofil) bis zu 2 oder bis zu 12³¹.
• Die Grundform der Fehlerbehandlung ist Try-Catch-Finally, aufgebaut aus Scopes und der Einstellung „Ausführungsbedingung konfigurieren“ (Configure run after). Die Ausführungsbedingung wird aus vier Zuständen gewählt: Succeeded (erfolgreich), Failed (fehlgeschlagen), Skipped (übersprungen) und TimedOut (Zeitüberschreitung)³⁴.
• Sobald Catch den Fehlschlag behandelt hat, schließen Sie mit einer Terminate-Aktion ab, die die Ausführung als „Failed“ protokolliert. Vergessen Sie das, zeigt der Ausführungsverlauf Erfolg, und der Fehlschlag wird verschluckt⁴³.
• Die standardmäßige Fehlerbenachrichtigungs-E-Mail ist auf „Fehlschläge mit bekannter Lösung“ beschränkt und hat eine 28-tägige Abklingphase — ein Mechanismus mit zu vielen Lücken, um sich vollständig darauf zu verlassen. Betrachten Sie eine eigene Benachrichtigung aus einem Catch-Block als Pflicht⁵.
• Der Ausführungsverlauf ist standardmäßig nur 28 Tage lang sichtbar. Ein Flow, der fortlaufend fehlschlägt, wird nach 14 Tagen automatisch abgeschaltet. „Erst einen Monat später bemerken, dass er stillstand“ ist konstruktionsbedingt durchaus möglich⁶¹.
• Bereiten Sie sich auf erneute Ausführungen (Resubmit) und doppelte Trigger vor, indem Sie von Anfang an ein idempotentes Design, das auch bei doppeltem Lauf sicher ist (ein Verarbeitet-Flag, Upsert statt Create, Triggerbedingungen), einbauen⁷⁸.

2. Wie ein Flow scheitert — vier Fehlerkategorien

Der Entwurf der Fehlerbehandlung wird deutlich einfacher, wenn man mit der Klassifizierung „wie scheitert es“ beginnt. Auch Microsofts eigene Anleitung fordert, davon auszugehen, dass Automatisierung scheitern kann und wird, und Dinge wie Wartung am verbundenen Dienst, API-Änderungen, Passwortänderungen und kurzzeitige Netzwerkausfälle einzuplanen². In der Praxis legt das Denken in den folgenden vier Kategorien die Reaktion fast automatisch fest.

Von diesen ist in der Praxis abgelaufene Berechtigungen oder Authentifizierung am lästigsten, weil dann nicht nur die Aktionen des Flows scheitern — der Trigger selbst beginnt zu scheitern. Eine Passwortänderung (oder ein Ablauf) bei den Anmeldedaten, die eine Verbindung verwendete, wird in Microsofts eigener Fehlerbehebungsanleitung als typisches Beispiel für einen mit einem 4xx-Fehler scheiternden Trigger genannt. Scheitert der Trigger, startet der Flow gar nicht erst, sodass der Ausführungsverlauf nicht einmal eine Zeile „Failed“ erhält und man es noch später bemerkt⁹. Da eine Verbindung an den einzelnen Benutzer gebunden ist, der sie erstellt hat, kann auch das Ausscheiden oder der Wechsel eines Mitarbeiters dazu führen, dass gleich mehrere Verbindungen auf einmal ausfallen.

Noch etwas Wissenswertes: Unbeachtete Fehlschläge führen dazu, dass der Flow selbst abgeschaltet wird. Ein Flow, dessen Trigger oder Aktionen fortlaufend fehlschlagen, wird nach 14 Tagen automatisch abgeschaltet, und einer, der fortlaufend gedrosselt wird, wird ebenso nach 14 Tagen abgeschaltet. Auch ein Flow, der 90 Tage lang nicht ausgelöst wird, kann abgeschaltet werden, sofern sein Besitzer keine Premium- oder Kapazitätslizenz besitzt¹. Ein Flow kann außerdem wegen einer Verletzung der DLP-Richtlinie oder wiederholter Fehlschläge in einen Zustand „ausgesetzt“ (suspended) geraten¹⁰. Ein gewisser Anteil von „der Flow lief doch, und ist dann einfach stehengeblieben“ ist gar kein Störfall — sondern genau diese Spezifikation am Werk.

3. Den Standard-Retry verstehen

Jede Aktion in Power Automate (das im Unterbau auf Azure Logic Apps aufbaut) besitzt von Anfang an eine eingebaute Retry-Richtlinie. Kennt man diese Spezifikation vorab genau, lässt sich beurteilen, ob man zusätzliche Retry-Konfiguration ergänzen sollte oder ob ein Retry das Problem überhaupt nicht löst.

Was wird wann erneut versucht

Die Retry-Richtlinie greift, wenn die Anfrage einer Aktion (oder eines Triggers) in ein Timeout läuft oder mit einer Antwort 408 (Request Timeout), 429 (Too Many Requests / Drosselung) oder 5xx (Serverfehler) fehlschlägt³. Die Standardrichtlinie ist exponentieller Backoff (erneuter Versuch bei exponentiell verlängertem Intervall), und in Power Automate hängen die Standardanzahl und das Standardintervall vom Leistungsprofil des Flows ab (das sich faktisch auf die Lizenzstufe zurückführen lässt)¹.

Mit anderen Worten: Selbst bei exakt derselben Flow-Definition unterscheidet sich, wie hartnäckig eine vorübergehende Störung durchgehalten wird, je nach Lizenz des Besitzers. Das Profil wirkt sich nicht nur auf die Anzahl der Wiederholungen aus, sondern auch auf die tägliche Obergrenze der Anfragenanzahl, sodass es sich lohnt, die Lizenzstufe als vollwertigen Bestandteil der Entwurfsüberlegungen zu behandeln.

Sie können die Retry-Richtlinie in den Aktionseinstellungen ändern. Es gibt vier Typen — Default (Standard), None (Keine), Fixed Interval (Festes Intervall) und Exponential Interval (Exponentielles Intervall) —, und Sie können Anzahl und Intervall explizit angeben. Die Konfigurationsgrenzen sind maximal 90 Wiederholungen, ein Mindestintervall von 5 Sekunden und eine maximale Verzögerung von 1 Tag³¹. Microsofts Coding-Richtlinien empfehlen für die Erholung von einer vorübergehenden Störung ein exponentielles Intervall gegenüber einem festen Intervall, damit man die Gegenseite nicht in kurzen Abständen weiter belastet und ihre eigene Erholung behindert⁴.

Was ein Retry löst — und was nicht

Zu beachten ist eines: Auch ein Retry verbraucht Anfragenanzahl (Power-Platform-Anfragen). Jede Aktionsausführung zählt zur Gesamtanfragenzahl, unabhängig von Erfolg oder Fehlschlag, und dasselbe gilt für Retry- und Paginierungsanfragen¹. Eine Anpassung in Richtung mehr Wiederholungen als Reaktion auf ein 429 kann die Drosselung sogar verschlimmern; bevor Sie also die Retries verstärken, prüfen Sie zuerst, ob sich schlicht die Anzahl der Aufrufe reduzieren lässt.

4. Das Try-Catch-Finally-Muster — Scopes und „Ausführungsbedingung konfigurieren“

Ein Fehlschlag, den ein Retry nicht lösen kann, muss innerhalb des Flows abgefangen und behandelt werden. Power Automate besitzt keine Try-Catch-Syntax als solche, aber Sie können dieselbe Struktur aufbauen, indem Sie einen Scope mit „Ausführungsbedingung konfigurieren“ (Configure run after) kombinieren. Das ist das Standardmuster, das auch Microsofts eigene Coding-Richtlinien empfehlen⁴.

Die Grundlage des gesamten Mechanismus ist die Ausführungsbedingung. Jede Aktion landet bei Abschluss in einem von vier Zuständen — Succeeded (erfolgreich), Failed (fehlgeschlagen), Skipped (übersprungen) oder TimedOut (Zeitüberschreitung) —, und standardmäßig läuft die nachfolgende Aktion nur „wenn die vorherige Aktion erfolgreich war“. Sie können diese Bedingung pro Aktion ändern und so eine Verzweigung bauen, die „bei Fehlschlag“ oder „bei Zeitüberschreitung“ läuft³.

Wendet man das auf einen Scope an, entsteht Try-Catch-Finally. Ein Scope rollt die Ergebnisse aller darin enthaltenen Aktionen zu einem einzigen Gesamtstatus zusammen, sodass eine Struktur wie „wenn irgendetwas innerhalb des Try-Scopes fehlschlägt, den Catch-Scope ausführen“ deutlich leichter zu warten ist, als für jede einzelne Aktion separat eine Ausführungsbedingung zu setzen³⁴.

flowchart TD
    Trigger[Trigger] --> Try[[Try-Scope<br/>Hauptverarbeitung hier bündeln]]
    Try -- Erfolg --> Fin
    Try -- Fehlgeschlagen / Zeitüberschreitung --> Catch[[Catch-Scope<br/>Ausführungsbedingung: Failed oder TimedOut]]
    Catch --> Extract[Mit der result-Funktion + Array-Filterung<br/>die fehlgeschlagene Aktion und den Grund extrahieren]
    Extract --> Notify[Besitzer per Teams / E-Mail benachrichtigen<br/>Flow-Name, fehlgeschlagener Schritt, Fehlerdetail, Ausführungs-URL]
    Notify --> Fin[[Finally-Scope<br/>Ausführungsbedingung: Succeeded, Failed, Skipped und TimedOut, alle vier]]
    Fin --> Cleanup[Aufräumen: Statusspalte des Verzeichnisses aktualisieren]
    Cleanup --> Judge{Wurde Catch durchlaufen?}
    Judge -- Ja --> Term[Terminate<br/>Status: Failed, Ausführung beenden]
    Judge -- Nein --> Done([Normale Beendigung])

Beim Zusammenbau gibt es vier Punkte.

• Setzen Sie die Ausführungsbedingung des Catch-Scopes auf sowohl „Failed“ als auch „Timed Out“. Entfernen Sie das standardmäßige „Succeeded“. Wählen Sie nur Failed aus, entgeht Ihnen unbemerkt eine Zeitüberschreitung etwa bei einem Genehmigungswartezustand oder einer verzögerten Aktion³.
• Holen Sie sich innerhalb von Catch die Details des Fehlschlags. Die Funktion result('IhrTryScopeName') gibt die Ergebnisse (Status, Ein-/Ausgaben, Fehlertext) der Aktionen unmittelbar innerhalb eines Scopes als Array zurück, sodass Sie durch Filtern dieses Arrays auf Einträge mit Status Failed oder TimedOut den Namen der fehlgeschlagenen Aktion und die Fehlermeldung in Ihre Benachrichtigung aufnehmen können³⁴. Filtern Sie nur nach Failed, kommt die Extraktion leer zurück, sobald Catch über eine Zeitüberschreitung erreicht wurde, wodurch der eigentlich entscheidende fehlgeschlagene Schritt aus der Benachrichtigung fällt. Es lohnt sich außerdem, die Ausführungs-ID aus der workflow()-Funktion zu ziehen und eine direkte Link-URL zum Ausführungsverlauf zu bauen — das erleichtert die Untersuchung erheblich⁴.
• Setzen Sie die Ausführungsbedingung des Finally-Scopes auf alle vier Zustände. Legen Sie hier Aufräumarbeiten ab, die Sie immer laufen lassen wollen, ob erfolgreich oder fehlgeschlagen — das Löschen temporärer Dateien, das Aktualisieren der Statusspalte des Verzeichnisses und Ähnliches.
• Beenden Sie eine fehlgeschlagene Ausführung als allerletzten Schritt mit einer Terminate-Aktion, die sie als „Failed“ protokolliert. Das ist der Punkt, der am leichtesten vergessen wird. Schließt Catch normal ab, endet die Flow-Ausführung insgesamt mit einer erfolgreichen letzten Aktion, und der Ausführungsverlauf verzeichnet „Succeeded“. Mit anderen Worten: Wenn Sie nur benachrichtigen und dann aufhören, wird der Fehlschlag im Ausführungsverlauf unsichtbar und entgeht der Überwachung sowie jeder späteren Auswertung. Setzen Sie den Status von Terminate vor dem Beenden auf Failed mit einer Fehlermeldung, bleibt er auch im Ausführungsverlauf als Fehlschlag verzeichnet⁴³. Allerdings dürfen Sie Terminate nicht direkt an das Ende des Catch-Scopes setzen. Terminate beendet die gesamte Ausführung an dieser Stelle sofort, sodass der nachfolgende Finally-Scope nie läuft — und genau das Aufräumen übersprungen wird, das im Fehlerfall am dringendsten gebraucht wird. Lassen Sie, wie im Diagramm gezeigt, Catch lediglich ein Fehler-Flag (eine Variable) setzen und bei der Benachrichtigung aufhören, werten Sie dieses Flag aus, nachdem das Aufräumen von Finally durchlaufen wurde, und beenden Sie erst dann im Fehlerfall mit Terminate.

Die Ausführungsbedingung ist außerdem der zentrale Baustein hinter der Timeout-Verzweigung eines Genehmigungs-Flows (Erinnerungen und Eskalation). Wie sich das konkret aufbauen lässt, wird in Einen Genehmigungs-Workflow in Power Automate erstellen — Papier- und E-Mail-basierte Genehmigungsanträge digitalisieren behandelt.

5. Mechanismen zum Bemerken von Fehlschlägen — Benachrichtigung und Sichtbarkeit

Fehlerbehandlung aufzubauen bringt nichts, wenn niemand den Fehlschlag bemerkt. Entwerfen Sie einen „Mechanismus zum Bemerken“ mehrschichtig, statt sich auf die Standardbenachrichtigung zu verlassen.

Die standardmäßige Fehlerbenachrichtigungs-E-Mail richtig verstehen

Power Automate besitzt zwar einen Mechanismus, der bei einem Fehlschlag eine E-Mail-Benachrichtigung sendet, doch wer sich darauf verlässt, ohne die Spezifikation zu kennen, findet ihn voller Lücken. Es gibt zwei Arten von Benachrichtigung⁵.

• Fehleralarm pro Ausführung: Wird unmittelbar nach dem Fehlschlagen einer Ausführung gesendet, aber nur, wenn der Fehlschlag als einer mit „bekannter Lösung“ eingestuft wird — eine unterbrochene Verbindung, Drosselung, ein bekannter Connector-Fehler und Ähnliches. Bei einem allgemeinen Aktionsfehlschlag wird er nicht gesendet. Er geht an Besitzer und Mitbesitzer (nicht an reine Ausführungsbenutzer) und niemals an Administratoren. Zudem tritt der betreffende Flow nach dem Versand in eine 28-tägige Abklingphase ein, während der bei weiteren Fehlschlägen kein zusätzlicher Alarm eintrifft. Alarme pro Ausführung sind zudem nicht standardmäßig für jeden Flow aktiviert; Sie müssen die Flow-Einstellungen prüfen⁵.
• Wöchentliche Fehlerübersicht: Einmal pro Woche wird eine Zusammenfassung der Fehlschläge über alle Umgebungen hinweg gesendet. Diese enthält auch die allgemeinen Fehlschläge, für die kein Alarm pro Ausführung gesendet wurde⁵.

Darüber hinaus wird bei bestimmten Fehlern eine E-Mail mit „Reparaturhinweisen“ (repair tips) samt Behebungsschritten an den Besitzer gesendet (die sich auch pro Flow abschalten lässt)⁷. Alles zusammengenommen ist der standardmäßige Benachrichtigungsmechanismus einer, bei dem man „die erste unterbrochene Verbindung bemerkt, ein durch Geschäftsdaten verursachter Fehlschlag oder ein zweiter und weiterer Fehlschlag jedoch tendenziell durchrutscht.“ Betrachten Sie für jeden wichtigen Flow eine eigene Benachrichtigung aus dem Catch-Block von Kapitel 4 als Pflicht.

Die Benachrichtigung aus Catch entwerfen — wenn die Benachrichtigung selbst fehlschlägt

Auch die eigene Benachrichtigung hat eigene Entwurfspunkte.

• Adressieren Sie sie nicht an eine Einzelperson. Senden Sie sie an eine bestimmte Person, erreicht sie niemanden mehr, sobald diese abwesend ist oder das Unternehmen verlassen hat. Der Versand an ein gemeinsam genutztes Postfach oder einen Teams-Kanal wird auch von der offiziellen Dokumentation selbst empfohlen¹⁰.
• Trennen Sie den Benachrichtigungsweg von der Hauptverarbeitung. Ein häufiger Störfall ist ein gemeinsamer Ausfall: Der Flow scheitert, weil seine Outlook-Verbindung abgebrochen ist, und auch die Fehlerbenachrichtigung kann nicht gesendet werden, weil sie dieselbe Outlook-Verbindung verwendet. Liegt die Ursache in einer abgelaufenen Authentifizierung, scheitert die Benachrichtigungsaktion, die dieselbe Verbindung teilt, direkt mit allem anderen zusammen. Für die Benachrichtigung einen anderen Connector und eine andere Verbindung als für die Hauptverarbeitung zu verwenden — etwa einen Teams-Beitrag — oder sie in einen kleinen, eigens dafür bestimmten Benachrichtigungs-Flow auszulagern, den man separat aufruft, senkt das Risiko eines solchen gemeinsamen Ausfalls. Dennoch lässt sich nicht endlos „eine Benachrichtigung für die Benachrichtigung“ bauen, sodass die im Folgenden beschriebene regelmäßige Prüfung als letzte Verteidigungslinie dient.
• Packen Sie alles, was für die Untersuchung nötig ist, in die Benachrichtigung. Den Flow-Namen, den Namen der fehlgeschlagenen Aktion, die Fehlermeldung, einen direkten Link zum Ausführungsverlauf. Ohne diese Angaben sagt eine Benachrichtigung nichts über „irgendetwas ist fehlgeschlagen“ hinaus und wird tendenziell ignoriert⁴.

Sichtbarkeit und regelmäßige Prüfungen

• Flow-Prüfung (Flow checker): Erkennt vor dem Speichern Fehler und Warnungen in der Flow-Definition. Machen Sie es sich zur Gewohnheit, diese Prüfung einmal auszuführen, nachdem Sie etwas aufgebaut haben¹¹.
• Regelmäßige Prüfung des Ausführungsverlaufs: Der Ausführungsverlauf eines Flows wird standardmäßig nur 28 Tage lang angezeigt⁶. Ein in eine Lösung (Solution) aufgenommener Flow kann Metadaten des Ausführungsverlaufs in Dataverse aufbewahren, doch auch dort beträgt die Standardaufbewahrung 28 Tage, und eine Verlängerung ist eine administratorseitige Einstellung¹². Für einen Produktions-Flow wird empfohlen, etwa einmal pro Woche zu prüfen — nicht nur reine Fehlschläge, sondern auch „abgebrochene Ausführungen“ (die durch die Steuerung der Nebenläufigkeit verursacht sein können) und „ein plötzlicher Rückgang der Ausführungsanzahl“ (ein Anzeichen, dass der Trigger nicht mehr auslöst)¹⁰.
• Zentrale Administratorüberwachung: Um jeden einzelnen Fehlschlag zu sehen — einschließlich derer, für die keine Alarm-E-Mail pro Ausführung gesendet wird —, ist die Funktion Monitor im Power-Platform-Administrationscenter die umfassendste Option. Sie lässt sich Fehlschlagsanzahlen und Fehlerdetails pro Flow oder pro Umgebung prüfen⁵.

Bei einem zeitgesteuerten Flow müssen Sie außerdem überwachen, ob er überhaupt ausgelöst wurde. Das Design zeitgesteuerter Flows mit Geschäftstagsprüfung und Monatsabschlussverarbeitung wird in Zeitgesteuerte Flows in Power Automate entwerfen — Monatsabschlussverarbeitung, Geschäftstagsprüfung und Erinnerungen in der Praxis behandelt.

6. Erneute Ausführung und Idempotenz — „Es bricht nicht, selbst wenn es zweimal läuft“ bauen

Die Behandlung eines Fehlschlags endet nicht mit dem Erkennen. Sie brauchen sowohl den Vorgang „den fehlgeschlagenen Teil wiederholen“ als auch ein Design, bei dem „das Wiederholen nichts kaputtmacht“, als Paket.

Die Spezifikation von Resubmit (erneut senden)

Eine fehlgeschlagene Ausführung lässt sich aus dem Ausführungsverlauf über Resubmit (Erneut senden) wiederholen. Sie läuft mit denselben Triggerdaten erneut — bei einer vorübergehenden Störung (500/502 usw.) genügt ein unverändertes erneutes Senden; lag die Ursache in einem Fehler der Flow-Definition, korrigieren Sie ihn, speichern Sie ihn und senden Sie ihn dann erneut, dann läuft er gegen die korrigierte Definition erneut⁷. Aus der Liste des Ausführungsverlaufs können Sie bis zu 20 Ausführungen auf einmal im Stapel erneut senden, was sich bei der Wiederherstellung nach einem Massenausfall als nützlich erweist. Bei einem manuell ausgelösten Flow (Instant Trigger) können Sie eigene Ausführungen jederzeit erneut senden, doch das erneute Senden einer von jemand anderem ausgelösten Ausführung erfordert, dass ein Administrator dies über eine Mandanteneinstellung zulässt¹³.

Wichtig ist dabei, dass ein erneutes Senden den Flow von ganz vorne aus ausführt. Senden Sie eine bei Schritt 8 von 10 fehlgeschlagene Ausführung erneut, laufen auch die Schritte 1 bis 7, die bereits erfolgreich waren, erneut. Genau daher stammen Störfälle wie „die E-Mail war schon gesendet worden, und wurde noch einmal gesendet“ oder „im Verzeichnis entstand dieselbe Zeile zweimal“.

Idempotenz — ein Design, das auch bei zweimaligem Lauf sicher ist

Bauen Sie also von Anfang an ein Design ein, bei dem eine beliebig oft wiederholte Ausführung mit demselben Input dasselbe Ergebnis liefert (idempotent). Das ist der eigentliche Kern des Fehlerdesigns — es schützt nicht nur vor erneutem Senden, sondern auch vor doppelten Triggerauslösungen und gleichzeitigen Ausführungen.

• Ein Verarbeitet-Flag führen. Geben Sie einem Verzeichnis wie einer SharePoint-Liste eine Spalte „Status“ (Unbearbeitet / In Bearbeitung / Verarbeitet); prüfen Sie den Status am Anfang des Flows und brechen Sie dort ab, falls bereits verarbeitet, und aktualisieren Sie den Status, sobald die Verarbeitung abgeschlossen ist. Tun Sie das, verursacht ein erneutes Senden keine Doppelverarbeitung mehr. Dieses Flag funktioniert allerdings nur, wenn Sie zusätzlich die Reihenfolge der Aktualisierungen festlegen. Bei einem externen Nebeneffekt wie dem Versenden einer E-Mail oder der Registrierung in einem Kernsystem aktualisieren Sie den Status unmittelbar zuvor auf „In Bearbeitung“, führen den Nebeneffekt aus und setzen ihn erst nach dessen Abschluss auf „Verarbeitet“. Eine Ausführung, die nach dem Nebeneffekt, aber vor der Flag-Aktualisierung fehlschlägt, bleibt bei „In Bearbeitung“ stehen — ein Zustand, in dem Sie tatsächlich nicht wissen, ob der Nebeneffekt durchgelaufen ist. Diese Zeile mechanisch erneut zu senden, könnte einen doppelten Versand verursachen; schließen Sie daher Zeilen mit „In Bearbeitung“ von der automatischen erneuten Ausführung aus, und lassen Sie stattdessen eine Person sie mit dem tatsächlichen Versand- oder Registrierungsergebnis abgleichen und von Hand auf „Verarbeitet“ oder „Unbearbeitet“ zurücksetzen. Bedenkenlos erneut ausführbar sind nur Zeilen, die bei „Unbearbeitet“ stehen.
• Statt eines bedingungslosen „Erstellen“ ein „Aktualisieren, falls vorhanden, sonst erstellen“ (Upsert) verwenden. Suchen Sie die vorhandene Zeile anhand eines garantiert eindeutigen Schlüssels (Bestellnummer, Antrags-ID usw.) und verzweigen Sie bei einem Treffer zum Aktualisieren, andernfalls zum Erstellen. Ein bedingungsloses „Element erstellen“ häuft bei jedem erneuten Lauf doppelte Zeilen auf. Umgekehrt gilt: Daten ohne eindeutigen Schlüssel lassen sich nicht idempotent machen, sodass die Festlegung einer Schlüsselspalte bereits in die Phase des Verzeichnisdesigns gehört.
• Unerwünschte Auslösungen mit Triggerbedingungen stoppen. Dass sich etwa ein Flow mit dem Trigger „Element erstellt oder geändert“ durch seinen eigenen Rückschreibvorgang selbst erneut auslöst, ist genau die Art von Mehrfachauslösung, die Sie mit Triggerbedingungen (trigger conditions) stoppen sollten, nicht mit einer nachgelagerten Bedingungsverzweigung. Ein Ereignis, das die Triggerbedingung nicht erfüllt, führt gar nicht erst zu einer Ausführung, verbraucht also weder Ausführungsanzahl noch Anfragen⁸.

Ein Vorbehalt hierzu: Ein Ansatz „prüfen, dann schreiben“ wie ein Verarbeitet-Flag oder Upsert wirkt gegen eine sequenzielle Wiederholung wie ein erneutes Senden, ist für sich genommen aber kein atomarer Schutz. Feuern zwei doppelte Triggerereignisse nahezu gleichzeitig, kann es zu einem Wettlauf kommen, bei dem beide Ausführungen „Unbearbeitet“ lesen und dann beide mit der Verarbeitung fortfahren. Bei einem Flow, bei dem gleichzeitige Auslösungen möglich sind, sollten Sie zur zuverlässigen Vermeidung von Duplikaten entweder mit der im nächsten Abschnitt behandelten Steuerung der Nebenläufigkeit bei einem Parallelitätsgrad von 1 serialisieren, oder dies mit einem Mechanismus auf der Speicherseite kombinieren, der eine Eindeutigkeitsbeschränkung erzwingen kann (etwa eine eindeutige Datenbankbeschränkung), sodass ein doppeltes Erstellen bereits beim Schreiben fehlschlägt.

Der Kompromiss zwischen Steuerung der Nebenläufigkeit und Reihenfolge

Neben der Doppelausführung ist das andere Problempaar „Nebenläufigkeit“ und „Reihenfolge“. Standardmäßig läuft der Flow, wenn zur selben Zeit eine große Zahl von Ereignissen die Triggerbedingung erfüllt, parallel mit so vielen Instanzen wie nötig¹. Lesen und schreiben mehrere Ausführungen gleichzeitig dieselbe Verzeichniszeile, kann es zu einer Inkonsistenz kommen, bei der ein veralteter Wert gelesen und dann überschrieben wird — ein Dirty Read¹⁴.

Schalten Sie die Steuerung der Nebenläufigkeit (Concurrency Control) in den Triggereinstellungen ein, können Sie den Parallelitätsgrad von 1 bis 100 angeben. Setzen Sie den Parallelitätsgrad auf 1, findet jeweils nur eine Ausführung gleichzeitig statt, wodurch Sie einer Verarbeitung in Reihenfolge näherkommen¹¹⁴. Dieser Schalter bringt jedoch einige gewichtige Vorbehalte mit sich.

• Einmal eingeschaltet, lässt es sich nicht mehr ausschalten. Der einzige Weg, es rückgängig zu machen, ist, den Trigger zu löschen und neu aufzubauen¹. Da die Steuerung der Nebenläufigkeit unumkehrbar ist, wird empfohlen, sie, wenn Sie sie anwenden, auf einen Flow mit wenigen Aktionen zu beschränken (bei Bedarf durch Auslagerung in einen Child-Flow)¹⁴.
• Sie schafft ein Risiko verlorener Ereignisse. Bei eingeschalteter Steuerung der Nebenläufigkeit ist die Anzahl der wartenden Ausführungen auf „10 + Parallelitätsgrad“ begrenzt; ein Trigger, der eintrifft, während diese Obergrenze überschritten ist, wird auf Connector-Seite erneut versucht, kann aber, wenn die Obergrenze lange überschritten bleibt, nie zu einer Ausführung gelangen. Die offizielle Dokumentation hält ausdrücklich fest, dass ein Flow, bei dem jeder einzelne Trigger zuverlässig zu einer Ausführung führen muss, die Steuerung der Nebenläufigkeit ausgeschaltet lassen sollte¹. Ist ein Ausführungsverlauf voller abgebrochener Ausführungen, kann diese Einstellung die Ursache sein¹⁰.

Mit anderen Worten: „Reihenfolge wahren“ und „nichts verlieren“ sind ein Kompromiss. Die Serialisierung bei Parallelitätsgrad 1 ist wirksam für Verarbeitungen mit geringem Volumen, bei denen die Reihenfolge wichtig ist — etwa die Vergabe von Laufnummern in einem Verzeichnis —, sollte aber nicht unbedacht für Verarbeitungen eingesetzt werden, die zu Spitzenzeiten eine Flut von Ereignissen erleben. Brauchen Sie zwingend sowohl Reihenfolge als auch Vollständigkeit gleichzeitig, haben Sie ein Terrain betreten, das, wie Kapitel 8 erörtert, außerhalb von Power Automate entworfen werden sollte.

7. Eine Design-Checkliste vor der Produktivsetzung

Bevor Sie einen neuen Flow in Produktion nehmen, prüfen Sie mindestens Folgendes.

Zwölf Punkte mögen nach viel klingen, doch mehr als die Hälfte davon muss man nur beim ersten Mal einmal durchdenken. Umgekehrt wird das „Nachrüsten“ bei einem Flow, der das übersprungen hat und bereits in Produktion gegangen ist, tendenziell nie tatsächlich erledigt — verstärkt durch die Scheu, etwas bereits Laufendes anzufassen —, bis es zu einem Störfall kommt.

8. Wie weit sollte man mit Power Automate gehen

Treibt man die Fehlerbehandlung weit genug, zeigen sich Anforderungen, die außerhalb des Terrains von Power Automate liegen. Hier ein grober Anhaltspunkt für die Grenzziehung.

Als Faustregel sehe ich das etwa so: Solange man das Verfahren zur Fehlerbehebung noch mündlich erklären kann, ist es Terrain für Power Automate; sobald man es nicht mehr ohne ein Diagramm erklären kann, ist es Entwicklungsterrain. Insbesondere Arbeit, die eine kompensierende Transaktion braucht — im System von Firma A registriert, bei Firma B fehlgeschlagen, rollt man also A zurück? — ist komplexer, als die aufgeräumte Optik eines Flows vermuten lässt, und mit Terminate plus Benachrichtigung ist es damit nicht getan.

9. Zusammenfassung

„Der Flow lief doch, und ist dann einfach stehengeblieben“ ist so gut wie nie Pech — es ist so gut wie immer ein Designproblem. Ein Flow wird früher oder später scheitern, ganz gleich was. Von den vier Fehlerkategorien kümmert sich ein Retry nur um vorübergehende Störungen; datenbedingte Fehlschläge, abgelaufene Authentifizierung und Spezifikationsänderungen lassen sich nur durch einen mehrschichtigen Mechanismus auffangen: Try-Catch zum Abfangen, Terminate zum Protokollieren, eine eigene Benachrichtigung und eine wöchentliche Prüfung des Ausführungsverlaufs. Die standardmäßige Fehlerbenachrichtigungs-E-Mail ist ein begrenzter, bedingter Mechanismus mit 28-tägiger Abklingphase, und ein Betrieb, der davon ausgeht, dass sie alles abfängt, lässt garantiert etwas durchrutschen.

Und der eigentliche Kern der Fehlervorsorge ist nicht die Benachrichtigung — es ist die Idempotenz. Gestalten Sie die Dinge so, dass „es nicht kaputtgeht, selbst wenn es zweimal läuft“, mit einem Verarbeitet-Flag und Upsert, und weder erneutes Senden noch ein doppelter Trigger sind mehr etwas, wovor man sich fürchten muss — die Wiederherstellung wird schlicht zu „die fehlgeschlagenen auswählen und erneut senden“. Umgekehrt ist es bei Arbeit, die eine kompensierende Transaktion oder eine strikte Reihenfolgegarantie braucht, nicht die Lösung, sie mit Gewalt in Power Automate zu pressen; die Entscheidung, sie in einen Entwicklungsaufwand auszulagern, ist langfristig günstiger. Der Tag, an dem Ihr Flow zum ersten Mal live geht, ist genau der richtige Tag, um diese Checkliste einmal durchzugehen.

Verwandte Artikel

• Geschäftsprozesse mit Power Automate automatisieren — Cloud-Flows, Desktop-Flows und robuste Fehlerbehandlung
• Zeitgesteuerte Flows in Power Automate entwerfen — Monatsabschlussverarbeitung, Geschäftstagsprüfung und Erinnerungen in der Praxis
• Einen Genehmigungs-Workflow in Power Automate erstellen — Papier- und E-Mail-basierte Genehmigungsanträge digitalisieren

Verwandte Beratungsbereiche

Die KomuraSoft LLC übernimmt alles von der Überprüfung von Fehlerbehandlung und Betriebsdesign für Power-Automate-Flows bis zum systemseitigen Aufbau von Reihenfolgegarantien und Transaktionsanforderungen, die ein Flow allein nicht abdecken kann.

• Technische Beratung & Design-Review
• Windows-App-Entwicklung
• Kontakt

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Wird bei einem Fehlschlag eines Power-Automate-Flows automatisch eine Benachrichtigungs-E-Mail versendet?

Nur eingeschränkt. Die Fehleralarm-E-Mail pro Ausführung wird nur an Besitzer und Mitbesitzer gesendet, wenn der Fehler als einer mit „bekannter Lösung“ eingestuft wird — etwa eine unterbrochene Verbindung oder Drosselung (Throttling) — nicht bei einem allgemeinen Aktionsfehler. Zudem tritt der betreffende Flow nach dem Versand in eine 28-tägige Abklingphase ein, während der keine weiteren Alarme eintreffen. Fehleralarme pro Ausführung sind zudem nicht standardmäßig für jeden Flow aktiviert. Um einen Fehler zuverlässig zu bemerken, empfehlen wir, eine eigene Benachrichtigung per Teams-Nachricht oder E-Mail aus einem Catch-Block heraus zu bauen.

Wie oft und in welchen Abständen läuft der Standard-Retry von Power Automate?

Wenn die Anfrage einer Aktion in ein Timeout läuft oder mit einer Antwort 408, 429 oder aus der 5xx-Reihe fehlschlägt, wird standardmäßig automatisch erneut versucht, wobei sich das Intervall exponentiell verlängert. Die Anzahl hängt vom Leistungsprofil des Flows ab (das sich faktisch auf die Lizenzstufe zurückführen lässt): bis zu 2 Wiederholungen bei einem niedrigen Profil wie einer Microsoft-365-Lizenz und bis zu 12 Wiederholungen bei einem mittleren oder hohen Profil wie Power Automate Premium oder einer Process-Lizenz. Sie können die Retry-Richtlinie in den Aktionseinstellungen auf „Keine“, „Festes Intervall“ oder „Exponentielles Intervall“ ändern und die Anzahl bis zu einem Maximum von 90 konfigurieren. Durch Daten oder Konfiguration verursachte Fehler wie 400 oder 404 unterliegen keinen Wiederholungen.

Wie wiederhole ich (sende erneut) eine fehlgeschlagene Flow-Ausführung?

Öffnen Sie die fehlgeschlagene Ausführung im Ausführungsverlauf und wählen Sie „Erneut senden“ (Resubmit); sie wird dann mit denselben Triggerdaten erneut ausgeführt. Lag die Ursache in einem Fehler der Flow-Definition, korrigieren Sie den Flow, speichern Sie ihn und senden Sie ihn anschließend erneut — dann läuft er mit der korrigierten Definition erneut. Aus der Liste des Ausführungsverlaufs können Sie bis zu 20 Ausführungen auf einmal in einem Stapel erneut senden. Der Haken dabei: Ein erneutes Senden führt den Flow von ganz vorne aus, sodass bei einer teilweise erfolgreichen Ausführung auch die bereits erfolgreichen Schritte erneut laufen. Sie brauchen ein idempotentes Design (ein Verarbeitet-Flag, Schreibvorgänge, die ein Update einem Create vorziehen), damit das Ergebnis auch bei doppeltem Lauf nicht beschädigt wird.

Kann ein Flow deaktiviert werden, ohne dass es jemand merkt?

Ja. Ein Flow, dessen Trigger oder Aktionen fortlaufend fehlschlagen, wird nach 14 Tagen automatisch abgeschaltet. Ein Flow, der fortlaufend gedrosselt wird (Ratenlimits erreicht), wird ebenso nach 14 Tagen abgeschaltet. Auch ein Flow, der 90 Tage lang kein einziges Mal ausgelöst wurde, kann abgeschaltet werden, sofern der Besitzer keine Premium- oder Kapazitätslizenz besitzt. Da unbeachtete Fehler direkt zur Abschaltung eines Flows führen, ist es wichtig, einen Mechanismus zum Bemerken von Fehlern sowie eine regelmäßige Prüfung des Ausführungsverlaufs (standardmäßig 28 Tage) in den Betrieb einzubauen.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.