Try-Catch mit 'Configure run after' in Power Automate

Ein Absturz mitten in einem Flow ist ärgerlich, ein Absturz, den niemand bemerkt, ist gefährlich. Power Automate kennt kein eingebautes Try-Catch wie eine klassische Programmiersprache, aber mit der Kombination aus Scopes und der Einstellung Configure run after baust du dir genau dieses Muster selbst. Das Ergebnis ist ein Flow, der bei einem Fehler nicht einfach abbricht, sondern kontrolliert reagiert, protokolliert und im Zweifel Bescheid gibt.

In diesem Artikel zeigen wir dir Schritt für Schritt, wie du Try-, Catch- und Finally-Bereiche aufbaust, wie du die Ausführungsbedingungen dafür korrekt einstellst und wie du im Fehlerfall an die eigentliche Fehlermeldung herankommst. Die Grundlage dafür liefert die offizielle Dokumentation von Microsoft, konkret die Anleitung zu robuster Fehlerbehandlung und die Übersicht zu Bereichen in Cloud-Flows.

Warum Power Automate kein klassisches Try-Catch kennt

In Programmiersprachen fängst du eine Ausnahme mit einem Try-Catch-Block ab, der Code läuft im Try-Teil, ein Fehler springt automatisch in den Catch-Teil. Power Automate arbeitet anders: Jede Aktion hat eine Ausführen-nach-Bedingung, die standardmäßig auf „ist erfolgreich" steht. Schlägt eine vorherige Aktion fehl, wird die nachfolgende Aktion einfach übersprungen und der ganze Flow bricht ab, sofern du nichts anderes konfigurierst.

Genau hier setzt das Try-Catch-Muster an: Du gruppierst deine eigentliche Logik in einem Bereich (Scope), fügst einen zweiten Bereich für die Fehlerbehandlung hinzu und stellst dessen Ausführen-nach-Bedingung so ein, dass er nur bei einem Fehler im ersten Bereich läuft. Damit bekommst du strukturell dasselbe Verhalten wie ein Try-Catch, nur eben über die Oberfläche statt über Code konfiguriert.

Der Aufbau: Try-, Catch- und Finally-Bereich

Für ein vollständiges Fehlerbehandlungsmuster legst du drei Bereiche hintereinander an:

• Try: Ein Bereich mit deiner eigentlichen Geschäftslogik, also den Aktionen, die im Normalfall ausgeführt werden sollen.
• Catch: Ein zweiter Bereich direkt darunter, der ausschließlich dann läuft, wenn im Try-Bereich etwas schiefgeht. Hier protokollierst du den Fehler oder schickst eine Benachrichtigung.
• Finally: Ein dritter Bereich, der unabhängig vom Ausgang immer läuft, egal ob der Try-Bereich erfolgreich war oder nicht. Praktisch für Aufräumarbeiten wie das Schließen einer Verbindung oder das Setzen eines Statusfelds.

Jeden Bereich fügst du über Aktion hinzufügen und die Suche nach „Bereich" ein, ausführlich beschrieben in der Anleitung Bereiche erstellen und verwenden. Achte darauf, die Bereiche sinnvoll zu benennen, „Try", „Catch" und „Finally" sind auf einen Blick verständlich und machen den Flow auch für Kolleginnen und Kollegen lesbar, die ihn später übernehmen.

Schritt für Schritt: Configure run after einrichten

So stellst du die Ausführen-nach-Bedingung für den Catch-Bereich ein:

• Öffne den Catch-Bereich im Designer und wähle oben rechts das „..."-Menü aus.
• Wähle Configure run after (auf Deutsch „Ausführen nach konfigurieren").
• In der Liste erscheint der vorherige Bereich, also „Try", mit vier Kontrollkästchen: ist erfolgreich, ist fehlgeschlagen, wird übersprungen und das Zeitlimit wurde überschritten.
• Entferne das Häkchen bei „ist erfolgreich" und setze stattdessen die Häkchen bei „ist fehlgeschlagen", „wird übersprungen" und „das Zeitlimit wurde überschritten".
• Bestätige mit Fertig.

Damit läuft der Catch-Bereich nur noch, wenn der Try-Bereich eben nicht sauber durchläuft. Für den Finally-Bereich gehst du genauso vor, setzt dort aber alle vier Kontrollkästchen, also zusätzlich auch „ist erfolgreich". So wird dieser Bereich in jedem Fall ausgeführt, unabhängig davon, wie der Try-Bereich endet. Wichtig: Mindestens ein Kontrollkästchen muss immer aktiv bleiben, komplett leer lässt sich die Bedingung nicht speichern.

Den Fehler im Catch-Bereich auslesen

Ein Catch-Bereich, der nur weiß, dass etwas schiefgegangen ist, aber nicht was, hilft dir bei der Fehlersuche wenig. Um an die konkrete Fehlermeldung zu kommen, nutzt du im Catch-Bereich die Aktion Array filtern in Kombination mit der Ausdrucksfunktion `result()`, die den Status und die Ausgabe der vorherigen Aktionen zurückgibt. Aus dieser gefilterten Antwort liest du Fehlercode und Fehlertext aus und packst sie zum Beispiel in eine HTML-Tabelle erstellen-Aktion, die du per E-Mail verschickst oder in einer Fehlerprotokoll-Liste in SharePoint oder Dataverse speicherst.

Zusätzlich liefert die `workflow()`-Funktion Metadaten zum aktuellen Flowlauf, etwa die Umgebungs- und Flow-ID. Kombiniert mit der Aktion Zusammenfassen baust du dir daraus einen direkten Link zum fehlgeschlagenen Lauf, den du in die Benachrichtigung einbaust. So landet nicht nur die Information „ein Fehler ist aufgetreten" im Postfach, sondern gleich der Weg dorthin, wo du ihn beheben kannst.

Typische Stolperfallen

• Verschachtelungstiefe: Power Automate erlaubt maximal acht verschachtelte Ebenen aus Bereichen, Bedingungen, Switches und Schleifen. Wer Try-Catch-Muster ineinander verschachtelt, sollte diese Grenze im Blick behalten, sonst lässt sich der Flow nicht mehr speichern.
• Sammelstatus statt Einzelaktion: Schlägt ein Bereich fehl, meldet der Designer zunächst nur den Status „Fehlgeschlagen" für den gesamten Bereich. Welche einzelne Aktion darin tatsächlich verantwortlich war, siehst du erst, wenn du den Bereich im Ausführungsverlauf aufklappst.
• Trigger und Antwortaktionen gehören nicht in einen Bereich. Sie sollten außerhalb bleiben, damit der Flow sauber startet und antwortet.
• Zu viele Bereiche: Nicht jede einzelne Aktion braucht einen eigenen Bereich. Setze das Try-Catch-Muster gezielt dort ein, wo es wirklich einen Mehrwert bringt, etwa bei kritischen Schreibvorgängen oder externen Systemaufrufen, sonst wird der Flow unnötig unübersichtlich.

Wenn du dieses Muster in einem größeren, produktiven Flow zuverlässig einbauen möchtest oder unsicher bist, wo in deinem Prozess ein Catch-Bereich wirklich nötig ist, unterstützt dich die Power-Automate-Beratung von NordFlux dabei. Du behältst dabei die volle Kontrolle über deinen Flow und deine Daten, wir helfen nur beim sauberen Aufbau.

Häufige Fragen

Ist Configure run after dasselbe wie ein Try-Catch in einer Programmiersprache?

Technisch nicht, funktional schon. Power Automate hat kein eingebautes Ausnahmekonzept, mit dem eine Aktion automatisch in einen Fehlerpfad springt. Über die Ausführen-nach-Bedingung eines Bereichs erreichst du aber dasselbe Verhalten: Der Catch-Bereich läuft nur, wenn der Try-Bereich fehlschlägt, genau wie ein Catch-Block bei einer Ausnahme.

Muss ich für jede einzelne Aktion eine eigene Ausführen-nach-Bedingung setzen?

Nein. Wenn du deine Aktionen in einem Try-Bereich zusammenfasst, reicht eine einzige Configure-run-after-Einstellung für den gesamten Bereich, statt jede Aktion einzeln abzusichern. Genau das ist einer der praktischen Vorteile von Scopes gegenüber vielen einzelnen Ausführen-nach-Bedingungen auf Aktionsebene.

Was passiert, wenn ich beim Catch-Bereich versehentlich „ist erfolgreich" angehakt lasse?

Dann läuft der Catch-Bereich auch dann, wenn der Try-Bereich erfolgreich war, was dem Sinn eines Fehlerpfads widerspricht. Entferne für einen echten Catch-Bereich das Häkchen bei „ist erfolgreich" konsequent und aktiviere ausschließlich „ist fehlgeschlagen", „wird übersprungen" und „das Zeitlimit wurde überschritten".

Kann ich zusätzlich zu Configure run after auch eine Wiederholungsrichtlinie nutzen?

Ja, beides ergänzt sich gut. Eine Wiederholungsrichtlinie in den Aktionseinstellungen versucht zuerst, eine vorübergehend fehlgeschlagene Aktion automatisch erneut auszuführen, idealerweise mit exponenziell wachsenden Intervallen. Schlägt die Aktion auch nach allen Wiederholungen fehl, greift erst dann dein Catch-Bereich über die Ausführen-nach-Bedingung.

Wie finde ich heraus, welche Aktion innerhalb eines fehlgeschlagenen Bereichs das eigentliche Problem war?

Öffne den betroffenen Flowlauf im Ausführungsverlauf und klappe dort den fehlgeschlagenen Bereich auf. Da ein Bereich nach außen nur einen einzigen Sammelstatus meldet, siehst du die konkrete Fehlermeldung samt roter Markierung erst auf der Ebene der einzelnen Aktion innerhalb des Bereichs.