Power Automate validieren: Fehler und Wiederholungen

Einordnung und Geltungsbereich

Der Beitrag konzentriert sich auf Cloud-Flows. Desktop-Flows besitzen teilweise andere Mechanismen. Verfügbare Konnektoren, deren Verhalten und die eigene Konfiguration müssen am konkreten Stand geprüft werden.

Quellen: [1] [2]

Wiederholen ist nur dann sicher, wenn die fachliche Wirkung beherrscht wird

Betrachten Sie einen Timeout nicht automatisch als fehlgeschlagene Verarbeitung. Das Zielsystem kann die Änderung bereits gespeichert haben, obwohl die Antwort den Flow nicht erreicht. Ein erneuter Versuch benötigt daher eine geeignete Erkennung bereits verarbeiteter Vorgänge oder einen kontrollierten Abgleich.

Erfolgreiche Teilschritte bleiben nach einem späteren Fehler häufig bestehen. Der Prozess muss entscheiden, ob er an dieser Stelle fortsetzt, eine Gegenbuchung ausführt oder manuell geklärt wird. Eine allgemeine Fehlermail ohne Datensatzbezug hilft dabei wenig. Die Meldung sollte den betroffenen Vorgang und den nötigen nächsten Schritt erkennbar machen.

Quellen: [1] [2]

Den fachlichen Zustand nach jedem Schritt definieren

Ein Flow kann technisch laufen und fachlich unvollständige Ergebnisse hinterlassen. Beschreiben Sie deshalb je kritischer Aktion, welcher Datenzustand danach erwartet wird. Hat ein Vorgang nur begonnen, ist ein Datensatz bereits geschrieben oder wurde der Empfänger tatsächlich aktualisiert? Diese Unterscheidung ist besonders bei Unterbrechungen und Wiederholungen wichtig.

Microsoft beschreibt unter anderem Run-after-Einstellungen, Scopes, Retry Policies und Terminate-Aktionen. Diese Funktionen helfen beim Aufbau von Fehlerwegen. Ihre bloße Verwendung beweist aber nicht, dass ein Geschäftsprozess richtig wiederanläuft. Der Test muss die konfigurierte Reaktion und den tatsächlichen Datenbestand verbinden.

Erfassen Sie Auslöser, Verbindungen, technische Identitäten und Empfänger. Zwei Flow-Läufe können denselben Geschäftsfall betreffen. Eine Laufkennung allein ist deshalb kein ausreichender fachlicher Schlüssel. Legen Sie fest, wie Wiederholungen erkannt werden und wer unklare Zustände beurteilt. Das ist eine eigene methodische Ableitung aus dem Daten- und Prozessrisiko.

Quellen: [1] [2]

Technischen Fehler, Timeout und fachliche Ablehnung unterscheiden

Ein technischer Fehler kann bedeuten, dass ein Ziel nicht erreichbar war. Ein Timeout kann offenlassen, ob eine Aktion im Ziel bereits ausgeführt wurde. Eine fachliche Ablehnung bedeutet wiederum, dass der Empfänger die Nachricht erhalten, aber nicht wie vorgesehen verarbeitet hat. Diese Fälle brauchen nicht zwingend denselben Wiederanlauf.

Prüfen Sie außerdem übersprungene Aktionen. Eine Fehlerbenachrichtigung kann erfolgreich versendet werden, während die fachliche Hauptaktion fehlgeschlagen ist. Der Gesamtstatus sollte für die zuständigen Mitarbeiter verständlich bleiben. Eine grüne Benachrichtigungsaktion darf nicht als Beleg der erfolgreichen Geschäftsverarbeitung interpretiert werden.

Quellen: [1] [2]

Beispiel: der Empfänger schreibt, die Rückmeldung geht verloren

Das Szenario ist konstruiert. Ein Flow übermittelt Ergebnis E-41 an ein Zielsystem. Das Ziel speichert den Datensatz, seine Rückmeldung erreicht Power Automate jedoch nicht. Ein automatischer Retry startet. Ohne geeignete Wiederholungsregel kann ein zweiter Datensatz entstehen. Eine bloße Verlängerung des Timeouts behandelt dieses Risiko nicht vollständig.

Definieren Sie eine Geschäftskennung, die den vorgesehenen Vorgang eindeutig bezeichnet. Prüfen Sie im Test einen normalen Lauf, eine doppelte Anforderung und einen unklaren Rückmeldezustand. Vergleichen Sie die tatsächlichen Zielobjekte. Ein geeigneter Ablauf erkennt die bereits erfolgte Verarbeitung oder behandelt sie über einen kontrollierten Klärungsweg. Der konkrete Mechanismus hängt vom Empfänger ab.

Erhalten Sie sowohl Laufbezug als auch Geschäftsbezug. Die Fehlerakte sollte erklären, welche Daten betroffen waren und ob eine manuelle Nachbearbeitung erfolgte. Ein erneuter Lauf mit verändertem Input ist kein identischer Retry und muss entsprechend eingeordnet werden. Benennen Sie, wer eine solche Änderung entscheiden darf.

Quellen: [1] [2]

Fehlerpfade, Run after und Benachrichtigungen prüfen

Legen Sie für kritische Aktionen fest, welche Folgeschritte nach Erfolg, Fehler, Timeout oder Überspringen ausgeführt werden sollen. Überprüfen Sie die tatsächlich gesetzten Run-after-Bedingungen. Ein nicht erreichter Catch-Pfad kann eine Lücke lassen, obwohl ein Fehlerhandling optisch vorhanden ist. Testen Sie die Zustände gezielt statt nur den normalen Ablauf.

Eine Benachrichtigung benötigt betroffenen Vorgang, verständlichen Zustand und nächsten Schritt. Vermeiden Sie, sensible Inhalte unnötig in E-Mails oder frei zugängliche Logs zu kopieren. Für die fachliche Klärung kann ein geschützter Verweis auf den Vorgang geeigneter sein. Die erforderliche Information richtet sich nach Aufgabe und Zugriff der Empfänger.

Prüfen Sie, ob Benachrichtigung selbst ausfallen kann. Ein Fehlerweg, der ausschließlich von derselben gestörten Verbindung abhängt, ist möglicherweise nicht zuverlässig. Das bedeutet nicht, dass jede Anwendung ein aufwendiges zweites Monitoring braucht. Bewerten Sie die Erkennung entsprechend der Kritikalität und der möglichen Dauer unbemerkter Fehlverarbeitung.

Quellen: [1] [2]

Wiederanlauf und manuelle Nachbearbeitung begrenzen

Definieren Sie, wann ein automatischer Retry sinnvoll ist und wann eine fachliche Entscheidung benötigt wird. Vorübergehende Nichterreichbarkeit kann anders behandelt werden als ungültige Stammdaten. Eine wiederholte fachlich falsche Nachricht wird durch häufigeres Senden nicht richtig. Grenzen, Pausen und Eskalation sollten zur Zielanwendung und zum Geschäftsprozess passen.

Manuelle Nachbearbeitung sollte die ursprüngliche Lauf- und Datenreferenz erhalten. Dokumentieren Sie Anlass, Änderung und Ergebnis. Eine Korrektur direkt in einer Datenquelle kann spätere automatische Wiederholung beeinflussen. Prüfen Sie deshalb, ob der Flow noch aktiv ist und welche weiteren Aktionen er auslösen kann. Unkontrollierter Parallelbetrieb von manueller und automatischer Bearbeitung erzeugt neue Unsicherheit.

Übergeben Sie ein kurzes Betriebsverfahren mit Beispielen. Ein Mitarbeiter sollte erkennen können, ob er erneut starten darf, zuerst den Zielzustand prüfen muss oder eskaliert. Eine lange technische Fehlermeldung ohne fachlichen Bezug hilft dabei wenig. Die Anleitung sollte auf die tatsächlich möglichen Zustände zugeschnitten sein.

Quellen: [1] [2]

Änderungen und Aufbewahrung der Nachweise

Versionieren Sie die relevanten Flow-Regeln und dokumentieren Sie Verbindungen, Wiederholungseinstellungen und kritische Bedingungen. Eine Änderung im Fehlerpfad kann ebenso bedeutend sein wie eine neue Hauptaktion. Regressionstests sollten deshalb auch Timeout, Teilverarbeitung und Wiederanlauf berücksichtigen, wenn diese Risiken vorhanden sind.

Prüfen Sie, welche Laufdaten wie lange verfügbar sind und welche Nachweise unabhängig davon erhalten werden müssen. Eine begrenzte technische Laufhistorie ist nicht automatisch eine geeignete langfristige Aufzeichnung für Ihren GxP-Prozess. Benötigte Geschäfts- und Korrekturinformationen sollten über einen begründeten, zugänglichen Aufbewahrungsweg verfügbar bleiben.

Bewerten Sie wiederkehrende Fehler als mögliche Prozesssignale. Wenn dieselbe Nachricht ständig manuell repariert wird, kann eine Ursache in Mapping, Stammdaten oder Anforderungen liegen. Ein erfolgreich abgeschlossener Einzelrun beendet diese systemische Frage nicht. Verbinden Sie technische Störung, fachliche Abweichung und gegebenenfalls Ursachenmaßnahme angemessen.

Quellen: [1] [2]

Arbeitsvorlage: einen unklaren Lauf ohne Datenverlust wiederanlaufen lassen

Beginnen Sie den Wiederanlauf mit einer Bestandsfrage: Was hat die Quelle gesendet und was hat das Ziel tatsächlich verarbeitet? Eine Fehlermeldung allein beantwortet das nicht. Verknüpfen Sie Geschäftskennung und technische Läufe. Dadurch kann dieselbe fachliche Anforderung trotz mehrerer technischer Versuche eindeutig behandelt werden.

Die Betriebsanweisung sollte einen Mitarbeiter durch drei Zustände führen: sicher nicht verarbeitet, sicher verarbeitet und unklar. Für jeden Zustand wird der erlaubte nächste Schritt beschrieben. Ein pauschaler Neustartknopf ist schwach, wenn er Teilverarbeitung oder bereits geschriebene Daten nicht berücksichtigt.

Prüfen Sie die Anweisung mit einem Mitarbeiter, der den Flow nicht entwickelt hat. Er sollte anhand der verfügbaren Informationen den passenden Zweig erkennen. Fehlende Geschäftsreferenzen oder unverständliche Meldungen werden dadurch sichtbar. Verbessern Sie den Betriebsweg, bevor eine hohe Zahl realer Fehler manuell bearbeitet werden muss.

Quellen: [1] [2]

Die nächsten Schritte

• Kritische Schreibaktionen und ihre fachliche Wirkung erfassen.
• Fehler vor, während und nach der Zielverarbeitung unterscheiden.
• Wiederholung, Dublettenschutz und manuelle Klärung testen.
• Überwachung und Aufbewahrung benötigter Laufnachweise festlegen.