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 bauen Sie sich 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 Ihnen Schritt für Schritt, wie Sie Try-, Catch- und Finally-Bereiche aufbauen, wie Sie die Ausführungsbedingungen dafür korrekt einstellen und wie Sie im Fehlerfall an die eigentliche Fehlermeldung herankommen. 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 fangen Sie 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 Sie nichts anderes konfigurieren.

Genau hier setzt das Try-Catch-Muster an: Sie gruppieren Ihre eigentliche Logik in einem Bereich (Scope), fügen einen zweiten Bereich für die Fehlerbehandlung hinzu und stellen dessen Ausführen-nach-Bedingung so ein, dass er nur bei einem Fehler im ersten Bereich läuft. Damit bekommen Sie 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 legen Sie drei Bereiche hintereinander an:

• Try: Ein Bereich mit Ihrer 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 protokollieren Sie den Fehler oder schicken 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ügen Sie ü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 stellen Sie 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 gehen Sie genauso vor, setzen 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 Ihnen bei der Fehlersuche wenig. Um an die konkrete Fehlermeldung zu kommen, nutzen Sie 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 lesen Sie Fehlercode und Fehlertext aus und packen sie zum Beispiel in eine HTML-Tabelle erstellen-Aktion, die Sie per E-Mail verschicken oder in einer Fehlerprotokoll-Liste in SharePoint oder Dataverse speichern.

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

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, sehen Sie erst, wenn Sie den Bereich im Ausführungsverlauf aufklappen.
• 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 Sie dieses Muster in einem größeren, produktiven Flow zuverlässig einbauen möchten oder unsicher sind, wo in Ihrem Prozess ein Catch-Bereich wirklich nötig ist, unterstützt Sie die Power-Automate-Beratung von NordFlux dabei. Sie behalten dabei die volle Kontrolle über Ihren Flow und Ihre 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 erreichen Sie 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 Sie Ihre Aktionen in einem Try-Bereich zusammenfassen, 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 Ihr Catch-Bereich über die Ausführen-nach-Bedingung.

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

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