Building try/catch Logic with Run After
Power Automate doesn't have a built-in try/catch block, but every action's three-dot menu offers 'Configure run after,' which lets you specify whether that action should run when the previous one Is successful, Has failed, Is skipped, or Has timed out — chaining these settings is how you build custom error-handling paths.
Cricket analogy: It's like a team having a specific Plan B batting order that only activates if the top order collapses, rather than a generic 'something went wrong' response.
Retry Policies on Connector Actions
Most HTTP-based connector actions carry a default retry policy of four retries with an exponential backoff interval, which automatically re-attempts a failed call before the action is marked as failed — this quietly absorbs transient issues like a momentary 429 throttling response or a brief network blip. You can change this in the action's Settings to Fixed Interval, Exponential Interval with a custom count and interval, or None if you want a failure to surface immediately instead of being retried.
Cricket analogy: It's like a bowler getting up to four run-ups at a no-ball line judgment before the umpire finally rules against the delivery, absorbing a brief inconsistency.
Scope Actions and the try/catch/finally Pattern
Wrapping a group of actions in a Scope lets you treat them as a single unit for error handling: add a second Scope named something like 'Catch', configure its 'run after' to trigger when the first Scope Has failed, Is skipped, or Has timed out, and inside it use the result() expression — for example result('Try') — to identify exactly which action inside the Try scope failed and why.
Cricket analogy: It's like grouping an entire batting innings into one unit that either ends in a total or a collapse, with a dedicated post-mortem review triggered only if it collapses.
Terminate Action and Failure Notifications
The Terminate action explicitly ends a flow run with a status of Succeeded, Failed, or Cancelled and an optional custom error message, which is useful for deliberately failing a run when a business rule is violated even though no technical error occurred. Pairing Terminate inside a catch Scope with a notification action — an email or a Teams message summarizing which step failed and the error body — turns a silent failure into something a support person actually sees.
Cricket analogy: It's like an umpire explicitly declaring a match abandoned due to rain with a formal announcement, rather than just letting play quietly stop with no explanation to the crowd.
{
"type": "Http",
"inputs": {
"method": "POST",
"uri": "https://api.example.com/orders",
"body": "@triggerBody()"
},
"runtimeConfiguration": {
"retryPolicy": {
"type": "exponential",
"count": 4,
"interval": "PT7S",
"minimumInterval": "PT5S",
"maximumInterval": "PT1H"
}
}
}Combine a Try Scope and a Catch Scope: set the Catch Scope's Configure run after to trigger on 'has failed', 'is skipped', and 'has timed out' from the Try Scope, then use result('Try') inside Catch to inspect exactly which action failed and its error message.
Setting an action's retry policy to None on a step that calls a flaky external API means any transient blip immediately fails the run — make sure a Catch Scope and notification are in place before disabling retries, or failures will go straight to a failed run with no alert.
- Configure run after (Is successful / Has failed / Is skipped / Has timed out) is how Power Automate builds custom error-handling paths.
- Most connector actions default to 4 retries with exponential backoff, adjustable to Fixed Interval, custom Exponential, or None.
- Wrapping actions in a Scope lets you treat them as one unit for error handling.
- A Catch Scope's run-after should include Has failed, Is skipped, and Has timed out to cover all non-success paths.
- result('ScopeName') inside a Catch Scope reveals which specific action inside the Try Scope failed and why.
- Terminate lets a flow explicitly end as Succeeded, Failed, or Cancelled with a custom message, even without a technical error.
- Pair Terminate inside a Catch Scope with a notification action so failures are visible, not silent.
Practice what you learned
1. How do you build a custom error-handling path in Power Automate?
2. What is the default retry behavior for most HTTP-based connector actions?
3. Which run-after statuses should a Catch Scope typically be configured for?
4. What does result('Try') return inside a Catch Scope?
5. What can the Terminate action do that a normal failed action cannot?
Was this page helpful?
You May Also Like
Conditions and Branching
How the Condition and Switch actions let a flow evaluate expressions and branch execution down different paths.
Variables in Flows
How to declare, set, and accumulate values in flow-scoped variables, and where they go wrong inside loops.
Working with Data Operations
How Compose, Parse JSON, Select, Filter Array, and table actions reshape data inside a flow without external calls.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics