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

A crash in the middle of a flow is annoying; a crash nobody notices is dangerous. Power Automate has no built-in Try-Catch like a classic programming language, but by combining scopes with the Configure run after setting, you can build exactly this pattern yourself. The result is a flow that, on error, doesn't just abort but reacts in a controlled way, logs the issue, and notifies you if in doubt.

In this article, we show you step by step how to build Try, Catch, and Finally scopes, how to set up their run-after conditions correctly, and how to get to the actual error message when something fails. The basis for this comes from Microsoft's official documentation, specifically the guide on robust error handling and the overview of scopes in cloud flows.

Why Power Automate has no classic Try-Catch

In programming languages, you catch an exception with a Try-Catch block: the code runs in the Try part, and an error automatically jumps to the Catch part. Power Automate works differently: every action has a run-after condition, which by default is set to "is successful." If a previous action fails, the following action is simply skipped and the entire flow aborts, unless you configure it otherwise.

This is exactly where the Try-Catch pattern comes in: you group your actual logic into a scope, add a second scope for error handling, and set its run-after condition so it only runs if the first scope fails. This gives you structurally the same behavior as a Try-Catch, just configured through the interface instead of through code.

The structure: Try, Catch, and Finally scopes

For a complete error handling pattern, you create three scopes one after another:

• Try: A scope with your actual business logic, i.e. the actions that should run under normal conditions.
• Catch: A second scope directly below it that only runs if something goes wrong in the Try scope. Here you log the error or send a notification.
• Finally: A third scope that always runs regardless of the outcome, whether the Try scope succeeded or not. Useful for cleanup work such as closing a connection or setting a status field.

You add each scope via Add an action and searching for "Scope", described in detail in the guide Create and use scopes. Make sure to name the scopes sensibly; "Try", "Catch", and "Finally" are understandable at a glance and keep the flow readable for colleagues who take it over later.

Step by step: setting up Configure run after

Here's how you set the run-after condition for the Catch scope:

• Open the Catch scope in the designer and select the "..." menu in the top right.
• Select Configure run after (in German: “Ausführen nach konfigurieren”).
• The list shows the previous scope, i.e. "Try", with four checkboxes: is successful, has failed, is skipped and has timed out.
• Remove the checkmark from "is successful" and instead check "has failed", "is skipped", and "has timed out".
• Confirm with Done.

This means the Catch scope now only runs when the Try scope doesn't complete cleanly. For the Finally scope, you proceed the same way, but check all four checkboxes there, including "is successful". This way, this scope always runs, regardless of how the Try scope ends. Important: at least one checkbox must always stay active; the condition can't be saved completely empty.

Reading out the error in the Catch scope

A Catch scope that only knows something went wrong, but not what, doesn't help you much with troubleshooting. To get to the specific error message, you use the Filter array action in the Catch scope, combined with the result() expression function, which returns the status and output of previous actions. From this filtered response, you read out the error code and error text and put them into, for example, a Create HTML table action, which you send by email or store in an error log list in SharePoint or Dataverse.

In addition, the workflow() function provides metadata about the current flow run, such as the environment and flow ID. Combined with the Compose action, you can build a direct link to the failed run, which you include in the notification. This way, not just the information "an error occurred" lands in the inbox, but also the way to get right to where you can fix it.

Common pitfalls

• Nesting depth: Power Automate allows a maximum of eight nested levels of scopes, conditions, switches, and loops. If you nest Try-Catch patterns inside each other, keep this limit in mind, otherwise the flow can no longer be saved.
• Aggregate status instead of individual action: If a scope fails, the designer initially only reports the status "Failed" for the entire scope. You only see which individual action inside it was actually responsible once you expand the scope in the run history.
• Triggers and response actions don't belong inside a scope. They should stay outside so the flow starts and responds cleanly.
• Too many scopes: Not every single action needs its own scope. Use the Try-Catch pattern specifically where it really adds value, such as for critical write operations or external system calls, otherwise the flow becomes unnecessarily cluttered.

If you want to reliably build this pattern into a larger, production flow, or you're unsure where in your process a Catch scope is really necessary, NordFlux's Power Automate consulting can support you with that. You keep full control over your flow and your data; we just help with a clean setup.

Frequently asked questions

Is Configure run after the same as a Try-Catch in a programming language?

Technically no, functionally yes. Power Automate has no built-in exception concept that automatically jumps an action into an error path. But via a scope's run-after condition, you achieve the same behavior: the Catch scope only runs when the Try scope fails, just like a catch block on an exception.

Do I need to set a separate run-after condition for every single action?

No. If you group your actions inside a Try scope, a single Configure run after setting for the entire scope is enough, instead of securing each action individually. That's exactly one of the practical advantages of scopes over many individual run-after conditions at the action level.

What happens if I accidentally leave "is successful" checked for the Catch scope?

Then the Catch scope also runs when the Try scope was successful, which contradicts the purpose of an error path. For a genuine Catch scope, consistently remove the checkmark from "is successful" and enable only "has failed", "is skipped", and "has timed out".

Can I also use a retry policy in addition to Configure run after?

Yes, the two complement each other well. A retry policy in the action settings first tries to automatically rerun a temporarily failed action, ideally with exponentially growing intervals. Only if the action still fails after all retries does your Catch scope kick in via the run-after condition.

How do I find out which action inside a failed scope was the actual problem?

Open the affected flow run in the run history and expand the failed scope there. Since a scope only reports a single aggregate status to the outside, you'll only see the specific error message along with the red highlight at the level of the individual action inside the scope.