What it does

Designing a flow so that when automation can't finish the job, the work gets parked somewhere a human will find it, with enough context to act on — rather than dying in a run history nobody reads.

Key facts

• Run after settings are the mechanism. Every action can branch on the previous one having failed, timed out, been skipped or succeeded, and that's what gives you a path to a human.
• Group work into scopes and use run-after on the scope for a try/catch shape. The result() function inside the catch scope returns the outputs of the try scope, and a Filter array over it gets you the actual error.
• Retry policies handle transient failures and run before any of your error branches. Exponential is preferred over fixed because it spreads attempts out rather than hammering a struggling service.
• The workflow() function returns run metadata — environment name, flow name, run ID — which is how you build a clickable link back to the failed run for whoever picks it up.
• Terminate stops the flow with a status and message you choose, so a genuinely unrecoverable run is marked Failed rather than misleadingly Succeeded.
• Power Automate already emails flow owners about common critical failures such as broken connections and throttling. Application Insights is the supported route to proper alerting.
• Approvals have no built-in timeout. A parallel branch with a Delay action next to the approval is the standard way to build one.
• The connector docs warn against over-logging: excessive custom logging adds actions, costs performance and turns into an anti-pattern where alerts get ignored.

When to use / skip

Build the human path for anything where a silent failure has business consequence — money not paid, a customer not contacted, a record not created. The test is simple: if this run fails at 3am on a Saturday, who finds out and how. Skip elaborate exception handling on low-stakes internal automations where the owner's failure email is genuinely enough. Not every flow needs a queue and a rota, and building one for every flow is how the real alerts get lost.

Configuration decisions

• Where failed work goes — a Dataverse or SharePoint exception table, a Teams channel, an approval assigned to a support group, or a combination.
• Who owns the queue, and whether that's a named team or an unowned inbox that will quietly fill up.
• What the timeout is on any human step, and what happens when it fires — escalate, reassign, cancel or park.
• Whether a parked item can be resumed automatically once fixed, or whether a person re-triggers it. Resumability changes the design substantially.
• How much context to capture. Enough for someone to act without opening the run, without logging so much you drown.

Gotchas

• Run after conditions have to be set on every downstream action, not just the first. Miss one and the flow carries on into the failure branch and the success branch at once.
• A catch scope that itself fails leaves you with nothing. Keep it simple, and don't call the same fragile connector inside it that just broke.
• Terminate inside a scope behaves differently from what people expect. Test the run status you actually get before relying on it for reporting.
• Approvals wait indefinitely. Without a parallel timeout branch, a leaver's outstanding approval will hold a run open until the 30-day run duration limit.
• Reminder loops are easy to get wrong and turn into a person receiving the same notification hourly for a fortnight. Cap the count and make the escalation real.

Consultant notes

• Run the "who gets the 3am call" conversation in design, and get a named owner per exception queue written down. Unowned queues are the single most common post-go-live failure.
• Insist on one exception pattern across the flow estate rather than each maker inventing their own. Support teams can only learn one.
• Application Insights over hand-rolled logging where the client has the appetite. It's less flow logic, better alerting and someone else maintains it.
• Reminders and escalation always turn out to be requirements. Price them in the estimate rather than discovering them in UAT.

---

Worth revisiting whenever the client's support model changes, or if native timeout handling ever lands on the Approvals connector