Power Automate Retry and Error-Handling Patterns

Retry Policies

Retry policies automatically retry actions when they fail with timeouts or certain error responses (e.g., 408, 429, 5xx). Configure per action under Settings (⋯) → Retry policy.

Policy	Behavior	When to use
Default	Exponential backoff: up to 4 retries, intervals between ~5–45 seconds	Most connector actions. Good for 429 and temporary 5xx.
Exponential Interval	Custom count and min/max interval. Intervals grow exponentially.	429-throttled connectors. Give the service time to cool down.
Fixed Interval	Same delay between each retry (e.g., 30 seconds).	When you want predictable retry timing.
None	No retries. Fails immediately on error.	When retrying would make things worse (e.g., duplicate sends).

Tip: For 429 (throttling), use Exponential Interval with a higher count (e.g., 5) and longer max interval. Respect the Retry-After header when connectors return it.

Configure Run After

Run After controls when the next action runs based on the previous action's outcome. Default is "is successful." Use "has failed," "is skipped," or "has timed out" to create error branches.

Option	Triggers when	Use case
is successful	Previous action succeeded	Default happy path
has failed	Previous action failed	Send alert, log error, notify owner
is skipped	Previous action was skipped (e.g., condition branch)	Handle alternate paths
has timed out	Previous action timed out	Separate timeout handling from other failures

Pattern: Attach a "Send an email" or "Post to Teams" action with Run After = "has failed" or "has timed out" on your critical steps. Include workflow().run.name or run URL so you can jump straight to the failed run.

Scope for Error Handling

Wrap multiple actions in a Scope action. If any action inside fails, the Scope fails. Use Run After on the Scope to route to a single error handler instead of branching every step.

• Put related actions in one Scope. On Scope failure → send notification, log, or take corrective action.
• Use multiple Scopes for different phases (e.g., "Get data," "Process," "Write back"). Each can have its own error path.
• Terminate action: Use in error branches to stop the flow cleanly with a status (Failed, Cancelled) and message. Prevents the flow from continuing down the main path after handling the error.

Parallelism and Throttling

For each loops run in parallel by default. When each iteration hits the same connector (e.g., SharePoint), you can blow through rate limits fast.

• Degree of Parallelism: Set to 1 for "one at a time" to avoid connector throttling. Find it under Settings on the For each action.
• Delay between iterations: Add a "Delay" action inside the loop (e.g., 2–5 seconds) to space out calls.
• Batch instead of loop: If the connector supports batch operations, use them instead of one call per item.

Error Notification Pattern

• Scope around the main logic. On Scope failure, run an action that emails or posts to Teams.
• Include: flow name, run ID, error message from result('ScopeName') or body('FailedAction'), and a link to the run (Power Automate run URL with workflow().run.id).
• Use a Condition to check failed() or equals(result('ScopeName'), 'Failed') if you need to branch on specific failure types.

Microsoft Sources