Why Error Handling Matters in Production Flows
The default behaviour of a Power Automate flow when an action fails is to stop execution and mark the run as failed. For a prototype or a simple notification flow, this is acceptable. For a production flow that creates SharePoint items, sends approval emails, updates Dynamics 365 records, or triggers downstream processes, a silent failure without notification, logging, or recovery is a business risk. Data corruption, missed approvals, and compliance gaps are the real-world consequences of flows that fail silently.
The Power Automate platform provides four mechanisms for handling failures: the Scope action (which groups actions and catches errors from the group), Configure Run After (which controls whether a subsequent action runs based on the status of its predecessor), retry policies (which automatically re-attempt failed connector calls), and the Terminate action (which provides a controlled exit with a custom status and message). A production-grade flow uses all four in combination to cover the full spectrum of failure scenarios — transient connector errors, expected business logic failures, and unexpected runtime exceptions.
The investment in proper error handling pays dividends at the first production incident. When a flow fails at 2am on a Sunday and the on-call team receives a Teams notification with the flow name, the failing action, the error code, and a link to the run history — resolution is a matter of minutes. Without error handling, the failure may not be discovered until a downstream process or a user complaint surfaces it hours or days later.
The Scope Action as a Try/Catch Block
The Scope action is Power Automate's structural grouping mechanism — it is functionally equivalent to a try block in traditional programming. You place all the actions that constitute the "happy path" of your workflow inside a Scope named "Try". Below the Try scope, you add a second Scope named "Catch", configured via Run After to execute only when the Try scope has failed, timed out, or been skipped. This creates a clean separation between business logic and error handling logic.
Inside the Catch scope, you have access to the result() expression, which returns an array of action results from the Try scope — including which specific action failed, the error message, and the HTTP status code if the failure came from a connector call. This information is what you log to SharePoint and include in your Teams/email notification so the support team knows exactly what went wrong without needing to navigate the flow run history manually.
// Get all failed actions from the Try scope result('Try_Scope') // Get the first failed action name first(filter(result('Try_Scope'), item()['Status'] ne 'Succeeded'))['name'] // Get the error message from the first failure first(filter(result('Try_Scope'), item()['Status'] ne 'Succeeded'))['error']['message'] // Get the full error body for logging string(first(filter(result('Try_Scope'), item()['Status'] ne 'Succeeded'))['error'])
Name your Scope actions with meaningful identifiers — "Try_CreateSharePointItem" rather than "Scope". This makes result('Try_CreateSharePointItem') expressions self-documenting and makes the flow run history much easier to navigate during an incident.
Configure Run After for Conditional Branching
Every action in Power Automate has a Configure Run After setting that determines under what conditions the action executes relative to its predecessor. By default, all actions run only when the preceding action succeeds. The four status conditions you can select are: Succeeded, Failed, Skipped, and Timed Out. An action can be configured to run on any combination of these statuses.
The most common pattern is configuring a Catch scope to run when the Try scope has Failed, Timed Out, or Skipped. The Skipped status is critical to include — if the Try scope contains a Condition or Switch that evaluates no branches, the Scope itself is marked Skipped, not Failed. Without including Skipped in your Catch's Run After configuration, errors that manifest as skipped scopes will never trigger your error handler.
A second common pattern is using Configure Run After for graceful partial failures. If you have a flow that processes 50 items in a loop and one item fails, you might want to log the failure and continue with the remaining 49 rather than aborting the entire run. Add a "Log Failure" action after the item processing actions, configured to run on both Failed and Timed Out. This creates a per-item error log while allowing the loop to continue.
Retry Policies for Transient Failures
Many connector failures are transient — a SharePoint API throttling response (429), a momentary network interruption, or a downstream service temporarily unavailable. Power Automate's retry policies handle these automatically without requiring custom error handling logic. You configure retry policies on individual actions in the Settings panel, not at the flow level.
Power Automate offers three retry policy types: None (no retries), Fixed interval (retry N times with a fixed delay between attempts), and Exponential interval (retry N times with a delay that doubles after each attempt, with jitter to prevent thundering herd). For most SharePoint and Microsoft Graph connector calls, the Exponential interval policy with 4 retries, 5-second initial delay, and 50-second maximum delay handles the vast majority of transient failures. Microsoft's own guidance for SharePoint throttling recommends exactly this pattern.
{
"type": "exponential",
"count": 4,
"interval": "PT5S",
"minimumInterval": "PT5S",
"maximumInterval": "PT50S"
}
// ISO 8601 duration format:
// PT5S = 5 seconds, PT1M = 1 minute, PT1H = 1 hour
// Exponential policy: 5s, 10s, 20s, 40s (capped at 50s)
Do not apply exponential retry to actions that are not idempotent — for example, a "Send email" action should not retry on failure without checking whether the email was already sent. Retrying non-idempotent actions can result in duplicate data creation or duplicate notifications.
Error Notification Flow with Teams and Email
An error notification that reaches no one is useless. Define a clear ownership model before building notifications: for each flow in production, there must be a named owner (a person, not a shared mailbox) who receives error alerts. For high-volume flows, consider routing errors to a Teams channel rather than individual email — channel notifications are visible to the team and can be triaged collaboratively, and Teams messages support Adaptive Cards with action buttons that link directly to the flow run.
In the Catch scope, use the Post message in a chat or channel Teams connector action to send an Adaptive Card with the flow name, the failing action name, the error message, the timestamp, and a deep link to the Power Automate run URL. Construct the run URL using the expression concat('https://make.powerautomate.com/run/', workflow()['run']['name']). This turns every error notification into a one-click path to the run history, cutting incident response time significantly.
Centralised Error Logging to SharePoint
Teams notifications are great for immediate awareness, but they are ephemeral — they scroll off and cannot be queried. A SharePoint list provides a persistent, queryable error log that supports trend analysis, SLA reporting, and recurring failure detection. Create a list with columns: FlowName (text), ActionName (text), ErrorCode (text), ErrorMessage (multiline text), Timestamp (date-time), RunURL (hyperlink), and Resolved (yes/no). In the Catch scope, after the Teams notification, add a "Create item" action to write to this list.
Once error data accumulates in SharePoint, build a Power BI report on top of the list to visualise error frequency by flow, error types over time, and mean time to resolution. Share this report with the Power Platform Centre of Excellence team for monthly review. Patterns in the error log often reveal underlying issues that individual alert triage misses — for example, a SharePoint connector that fails every Monday morning points to a batch job that locks the list over the weekend.
Testing Error Paths Systematically
The most common mistake in Power Automate development is thorough testing of the happy path and zero testing of error paths. Error handling code that has never been executed is often broken. Build a deliberate testing protocol: for each Scope and Configure Run After configuration, create a test case that forces the failure condition. For connector actions, you can force a failure by temporarily pointing to an invalid URL or using an invalid credential. For SharePoint actions, target a list that does not exist.
Document expected behaviour for each test case: which actions should trigger, what should appear in the Teams notification, what should be written to the error log SharePoint list, and whether the flow run should terminate as Succeeded or Failed after the Catch scope completes. A flow that catches an error and logs it successfully should be configured to Terminate with status Succeeded (using the Terminate action at the end of the Finally scope) so that Azure Monitor alerting on flow failure rate is not triggered for handled errors.
Production Readiness Checklist
Before promoting a Power Automate flow to production, validate each item on this checklist. A flow that passes all items will handle the majority of production failure scenarios gracefully and give the support team everything they need for rapid resolution.
- Try/Catch Scope structure: Every business-logic action is inside a named Try scope. A Catch scope is configured with Run After set to Failed + Timed Out + Skipped.
- Retry policies: All connector actions calling external APIs have an Exponential retry policy with at least 3 retries. Actions that are not idempotent use Fixed or None.
- Error notification: Catch scope sends a Teams Adaptive Card to a named owner or team channel with the flow name, failing action, error message, and run URL link.
- Error logging: Catch scope writes a structured record to the central error log SharePoint list.
- Terminate action: End of flow uses Terminate with Succeeded for handled errors, so flow failure rate metrics only alert on unhandled failures.
- Error path tested: At least one forced failure test has been run and the notification and log entry were verified.
- Connection references: All connections use service accounts or managed identities, not personal accounts that may expire or be disabled.
Key Takeaways
Use the Scope action as a try/catch block — all business logic in a Try scope, all error handling in a Catch scope configured with Run After to catch Failed, Timed Out, and Skipped.
Include Skipped in your Catch's Run After conditions — scope errors that manifest as Skipped will silently bypass a Catch configured for Failed only.
Apply Exponential retry policies to idempotent connector actions — 4 retries with 5-second initial delay handles SharePoint throttling reliably.
Log every error to a central SharePoint list for trend analysis — Teams notifications create awareness, SharePoint creates an auditable history.
Test every error path before go-live by forcing failures deliberately — error handling code that has never run is likely broken.