How Do You Add Error Handling to a Power Automate Flow (Run-After, Scopes, and Retry)?

Detailed Explanation

By default, a Power Automate flow stops at the first action that fails and shows a red "Failed" status in run history — which tells you something broke, but nothing about what to do next. Without deliberate error handling, that often means a half-completed process (a record updated in one system but not the other, a notification never sent) sitting unresolved until someone happens to check run history and notice.

Three building blocks work together to change that:

1. Scope actions as try/catch/finally. A Scope action is just a container for a group of other actions — but combined with Configure Run After, three scopes named "Try," "Catch," and "Finally" replicate the try/catch/finally pattern familiar from general-purpose programming: Try holds the actual work, Catch holds the recovery or notification logic and is configured to run only when Try didn't fully succeed, and Finally (optional) holds cleanup or logging that should run either way.
2. Configure Run After. Every action in Power Automate has a Configure Run After setting (found via the action's "..." menu), which controls which of the previous action's outcomes — is successful, has failed, is skipped, has timed out — allow this action to run. This is the mechanism that turns a plain sequence of actions into a branching try/catch structure: the Catch scope's Configure Run After is set to trigger on the Try scope's failure, skip, or timeout, instead of only its success.
3. Per-action retry policies. Most connector actions carry a default retry policy (commonly 4 retries with exponential backoff, roughly 5-second intervals to start), which handles brief, self-resolving problems — a momentary timeout, a transient rate limit — without any manual intervention or Catch-scope logic. This can be adjusted per action (more retries, a longer or fixed interval, or disabled entirely for actions where retrying makes no sense, like sending a notification).

These layers are complementary. Retries resolve the failures that fix themselves within seconds; the Catch scope handles what's left once retries are exhausted or the failure isn't the retryable kind at all.

Building the Pattern

1. Group the actions that should be treated as one unit of work into a "Try" scope. This is usually the core business logic of the flow — the steps where a partial failure would leave something in a bad, half-done state.

2. Add a second Scope action named "Catch" immediately after it. Configure its Run After setting (on the Catch scope itself) to trigger when the Try scope "has failed," "is skipped," or "has timed out" — leaving "is successful" unchecked, since Catch should only run when something in Try didn't complete cleanly.

3. Inside Catch, use the result() expression to retrieve what actually failed. The expression result('Try') returns the status and error details of every action inside the Try scope, which lets the Catch branch log or notify with the specific error rather than a generic "something failed" message.

4. Add a "Finally" scope if cleanup needs to run regardless of outcome. Configure it to run after both Try and Catch complete, on any of their outcomes — useful for releasing a lock, updating a status field, or sending a completion log entry whether the flow succeeded or not.

5. Review and adjust retry policies on individual risky actions, particularly calls to external or third-party APIs more prone to transient errors than native Microsoft 365 connectors — a longer interval or a capped retry count can be worth setting explicitly rather than accepting the default everywhere.

6. Connect the Catch scope to an actual notification, not just a run-history entry nobody looks at — a Teams message, an email to the flow owner, or an entry in a tracking list, so a real failure gets a human's attention rather than sitting silently until the next manual check.

Things to Consider

• This is a construction-time practice, not a diagnostic tool. This page covers building a flow that handles its own failures gracefully; if you're troubleshooting a flow that has already stopped working, see why did your Power Automate flow suddenly stop running with no error (something changed outside the flow) or why was your Power Automate flow suspended or throttled (the platform actively intervened) for after-the-fact causes.
• Retrying isn't always the right response to a failure. Retrying a call that's failing because of a genuine rate limit, rather than a momentary blip, can make the underlying problem worse — the suspension and throttling page covers this specific failure mode in more depth.
• A flow with no error handling isn't necessarily wrong for its purpose. Low-stakes, easily-noticed, easily-rerun flows often don't justify the extra scopes and configuration — reserve this pattern for flows where an unnoticed partial failure would actually cost something.
• This is Power-Automate-specific construction, not general monitoring practice. How do you stop an automation from failing silently covers the platform-agnostic discipline of setting up alerts and checks across any automation tool; this page covers the specific in-flow mechanics (scopes, run-after, retry policy) that make a Power Automate flow itself resilient.
• Nested scopes work the same way as top-level ones. A Try scope can itself contain another Try/Catch pair around a particularly risky sub-step, if different parts of the same flow need independently handled failure paths.
• A raw HTTP action calling a system with no built-in connector needs this more than most steps. See how do you connect Power Automate to a system with no built-in connector for building that connection — an unhandled non-2xx response from a custom API call is exactly the kind of failure a Scope-based Try/Catch is built to catch.

Common Mistakes

• Leaving every action's Configure Run After at the default ("is successful" only). This is what causes a flow to simply stop with no further action when something fails — deliberately setting Run After on a Catch scope is what makes recovery logic actually trigger.
• Building a Catch scope but never connecting it to a real notification. A Catch branch that only logs to a variable nobody checks provides no more visibility than no error handling at all — route it to a place a person will actually see.
• Increasing retry counts or intervals without understanding why the action is failing. More retries against a genuine rate limit or a permanently broken connection just delays the eventual failure rather than preventing it — check whether the failure is actually transient before tuning retry policy upward.
• Wrapping the entire flow in one giant Try scope. A single all-encompassing scope makes the result() expression's error detail less specific — grouping actions into smaller, logically related scopes makes it easier to tell exactly which step failed.
• Assuming error handling replaces the need for monitoring. A well-built Catch scope still depends on someone paying attention to the notification it sends — pair this with the monitoring habits in the general failing-silently page rather than treating in-flow error handling as sufficient on its own.