Fehler mit Try, Catch und Finally abfangen
Quizfrage
Wie stellst du «Configure run after» beim Scope Catch ein?
Auflösung
- A) has failed und has timed out an, is successful ausRichtig. So läuft Catch nur, wenn im Scope Try etwas scheitert oder zu lange dauert.
- B) Alle vier Status anhaken, damit Catch immer läuftFalsch. So stellst du Finally ein. Catch würde sonst auch nach jedem erfolgreichen Lauf starten.
- C) Nur is successful anhaken, damit Catch nachfolgtFalsch. Dann liefe Catch nur, wenn alles klappt, also genau dann, wenn es nichts abzufangen gibt.
Worum es geht
Ohne Fehlerbehandlung bleibt ein Flow bei der ersten fehlerhaften Aktion stehen, und niemand erfährt davon. Mit drei Scopes baust du das Muster aus der Programmierung nach. Im Scope Try steht die eigentliche Logik. Der Scope Catch läuft nur, wenn Try scheitert: Unter «Configure run after» hakst du «has failed» und «has timed out» an und lässt «is successful» leer. Dort benachrichtigst du jemanden oder schreibst ein Protokoll. Der Scope Finally läuft immer, mit allen vier Status angehakt, und räumt auf. Mit result('Try') liest du im Catch aus, welche Aktion gescheitert ist. Soll der Lauf in der Übersicht als fehlgeschlagen erscheinen, setzt du im Catch eine Terminate-Aktion mit dem Status Failed.
Der Ausdruck aus dem Tipp
result('Try')Wann einsetzen, wann nicht
Einsetzen
In jedem Flow, dessen Ausfall jemand bemerken muss: Schnittstellen, Dateien, Datensätze in Dataverse.
Lieber nicht
Bei einem kurzen Testflow, den du selbst startest und dessen Lauf du direkt verfolgst.
Häufigster Fehler
Kritische Aktionen ausserhalb des Scopes Try lassen. Was dort scheitert, sieht Catch nie.
Lizenz
Standard Läuft ohne Premium-Connector, also mit der Lizenz aus Microsoft 365. Beleg bei Microsoft Learn: Power Automate licensing FAQ. Für deinen ganzen Flow: Lizenz-Check.
Teilen
Kurzadresse: powerautomate.ninja/15
Quelle: PowerPlatformTip #15, Microsoft Learn: Employ robust error handling.