The default Power Automate error handling: the flow fails, a Microsoft email goes to whoever owns the flow — checked occasionally. This is not error handling.
Configure run-after for critical paths
Every action has a Run after configuration. Build parallel error branches using Run after → has failed. These branches can send notifications, log errors, or trigger remediation flows.
Try/catch with Scope actions
Wrap critical logic in a Scope action. Create a second Scope configured to run after the first has failed. Inside the catch: log the error, send a notification, trigger a fallback path.
Centralised error logging
Every production flow should write errors to a centralised log — a Dataverse table or SharePoint list. Include: flow name, run ID, timestamp, error action, error message, and environment.
Alerting that reaches the right people
Error notifications should go to a monitored Teams channel — not the personal inbox of the developer who built the flow.
Retry logic for transient failures
Configure retry policies on actions calling external services. Three retries with exponential backoff is a reasonable default for most HTTP and connector actions.
A flow with good error handling tells you the moment something goes wrong and why. This should be the standard for any production flow.
Error handling is not optional for production flows. Every flow that matters to the business should have explicit error handling configured before go-live.
