Use Run after and scopes to handle flow failures

Run after controls whether an action runs based on the status of the previous action. Grouping related actions in a Scope lets you use that setting for a flow-level error-handling pattern. It doesn’t automatically wrap every action in a try/catch block.

Route failures to a Catch scope

1. Put the main actions in a Scope named Try.
2. Add a second Scope named Catch.
3. Open Configure run after on Catch and select has failed and has timed out for Try. Select is skipped only if a skipped Try scope should also trigger your handler.
4. In Catch, use result('Try') to inspect the results of the actions in the scope. Log the details needed to diagnose the failure, then notify the right owner or terminate the flow with a clear status.

The scope groups actions for handling. Run after still evaluates the status of the preceding action or scope, so check that the scope reports the outcome you expect.

Retry transient failures separately

Use an action’s retry policy for transient connector or service failures. Before retrying an operation, check whether it is safe to run more than once. A notification or a log entry can make failures visible, but it doesn’t make a non-idempotent action safe to repeat.

Add a cleanup path

If the flow needs cleanup after either success or failure, add a final Scope after Catch. Configure its Run after settings for each outcome of Catch that should lead to cleanup, including is skipped if Try succeeds and Catch is skipped. Test both paths in run history. The final Scope only runs for the outcomes you select.

Sources

• Employ robust error handling, Microsoft Learn