A purchase request is approved, but Power Automate cannot save it in the purchasing list. The approver sees a confirmation anyway. Define what must succeed before sending that confirmation, and give staff a way to recover requests whose status is uncertain.

Make the completion message depend on the write

Give each request a stable reference. Group the actions that validate and save it, then send the success message only after the required write has succeeded. Microsoft’s Power Automate error-handling guidance explains how scopes and Run after settings can route failures, timeouts and skipped actions. Review which states your exception path should handle. A skipped step may mean an earlier dependency failed or that an action was intentionally bypassed.

Give the operator enough context to act

Log the request reference, time, failed stage and flow run reference in a place the responsible team can access. Send the request to a named queue with a recovery owner. Keep sensitive form values and credentials out of alerts. Decide how staff will spot a failure in the alert or logging step itself. A simple comparison of received requests against completed records can expose gaps even when a notification was missed.

Reconcile a timed-out write before repeating it

A destination may have committed the row before the connector timed out. Check for the request reference before retrying. Where the destination supports a uniqueness rule, use it to prevent a repeat write for the same reference. If the row exists, check its values before marking the request complete. Treat failure to notify as its own case when the purchasing record already exists.

Test a successful request, a rejected write, an uncertain timeout and a failure in the notification step using synthetic data. Confirm which message staff see and whether any duplicate record appears. For shared Excel workbooks, see the separate guide to concurrent spreadsheet writes.

ITZ’s Power Automate solutions service can review completion conditions and the exception queue. Share which step fails and what your staff currently see.

Review your flow failure recovery

Bring the workflow stages, destination and an anonymised example of a failed run. Use the form to discuss logging, safe retry and operator handover. Review Your Flow Failure Recovery