Handle workflow exceptions without losing or duplicating work
Plan recovery for missing data, failed connections and uncertain outcomes, including safe retries and manual repair.
Exception handling begins with deciding what a failure means for the business item being processed. A failed connection, missing customer detail and uncertain send result need different responses. The aim is to leave each item in an understandable state from which an authorized person or a controlled retry can continue.
Classify failures by the next safe action
Use separate categories for invalid input, missing business information, permission failures, temporary service problems and uncertain outcomes. Invalid data needs correction; expired access needs an owner to repair the connection. Repeating either request automatically is unlikely to solve it and may conceal a persistent problem behind a growing run history.
Preserve the item identifier, completed steps and failed operation. Avoid retaining unnecessary personal content in error messages. Give staff a concise business description and a link to detailed diagnostics they are allowed to view. A customer record should remain traceable even when its notification or downstream update has failed.
Retry only operations that are safe to repeat
Before retrying a write or send, determine whether the previous attempt might already have succeeded. A timeout means the answer was not received; it does not necessarily mean the action never occurred. Use provider identifiers, stored completion records or supported idempotency controls to reconcile the outcome before attempting the action again.
For temporary failures, set a bounded retry policy with increasing delays and a clear stopping point. Microsoft’s Power Automate guidance documents error scopes and retry handling, but the correct policy depends on the action. Do not wrap a whole sequence in repeated execution when some earlier steps create irreversible external effects.
Provide an operational recovery path
Give unresolved cases a visible status and a named owner. The repair view should show what can be corrected, what has already happened and which step will run next. Require confirmation for replaying customer communications or other consequential actions, and record manual changes so later troubleshooting can distinguish them from automated decisions.
Rehearse failures before launch using controlled test data. Disconnect a test account, supply an invalid record identifier and simulate a slow response. Check both the technical status and the resulting business records. A handled error should not appear as completed work simply because the workflow successfully posted an internal failure notification.
Practical checklist
- Classify input, access, temporary and uncertain failures.
- Record completed side effects before retrying.
- Limit retries and route unresolved items to an owner.
- Test recovery from the exact point of failure.
Illustrative setup: an uncertain CRM write
A request creates a deal, but the connector times out before returning its identifier. The workflow records an uncertain state and checks for the request’s unique reference in the CRM. If the deal exists, processing continues from that record. It does not immediately create a second deal or resend the customer acknowledgement.
Common questions
Should a failed item stop the entire queue?
Usually only when the failure suggests a shared problem, such as revoked access or a broken schema. An isolated missing field can wait for correction while independent valid items continue.
Is an error email enough?
No. Notifications need an actionable record, an owner and a recovery path. Otherwise the failure simply moves from an application into somebody’s inbox.
Further reading
Start with your actual workflow.
Turn the useful parts of this guide into a focused project brief.
Shape your project