What it does

A shortlist of the failures that actually turn up on real projects, and what the error looks like when they do. Most production flow incidents are one of about six things, and recognising the shape saves you an afternoon in run history.

Key facts

• Authentication failures show as Unauthorized, or HTTP 401 / 403. The fix is repairing the connection, then resubmitting.
• Configuration failures show as Bad request or Not found, or HTTP 400 / 404. Something in the action is pointed at the wrong thing, or the thing moved.
• Transient failures show as 500 or 502. Microsoft's guidance is simply to resubmit.
• Conditional Access mismatches produce a specific pattern: the flow works from make.powerautomate.com but fails when run from SharePoint, Teams or Excel. The host app performs a token exchange with Microsoft Flow Service (application ID 7df0a125-d3be-4c96-aa54-591f83ff541c) and different CA requirements on the two apps break it. A Terms of Use grant control can break existing connections retroactively, because silent token refresh can't present an acceptance page.
• Throttling shows up as runs stacking in the Waiting state. A throttled flow's queue stays stuck until capacity is added — Process licences add capacity per flow and can be stacked on a single cloud flow.
• Concurrency limits leave runs in Waiting behind the ones currently executing. This looks identical to throttling and to a stuck bulk cancel.
• DLP and tenant isolation breaches suspend the flow rather than failing it, with a suspension reason available through the API. Tenant isolation breaches fail at runtime and show as an ordinary failed run.
• Repair tips are emailed to flow owners automatically on failure, with a description of the problem, suggested fix, failure count and a link to retry with the same input data. Owners can turn them off per flow.
• Troubleshoot in Copilot summarises the error in plain language in the new designer and often suggests a fix.

When to use / skip

Work the list before you work the logic. When a flow that ran for eight months starts failing, the cause is almost never the flow — it's a connection, a licence, a policy change or a schema change upstream. Check what changed in the environment before you read a single expression. The exception is a flow that's never worked, where it usually is the logic and you should go straight to run history.

Configuration decisions

• Whether flows own their errors — try/catch scopes with Configure run after — or fail loudly and rely on run history.
• Whether connections are owned by named users or service principals, since expired-connection failures are the most common single cause and named accounts are the reason.
• Whether the client's Conditional Access policies target Office 365 / All cloud apps, or individual apps with differing requirements.
• Concurrency control settings per flow, and whether the queue behaviour under load is understood before go-live rather than after.
• Whether schema-dependent actions parse JSON with a fixed schema (fails loudly on drift) or navigate loosely (fails quietly, later, wrongly).

Gotchas

• Null and schema drift is the quiet one. An upstream system starts omitting a field, Parse JSON either throws or lets a null through, and the flow succeeds while writing rubbish. Success status is not the same as correct outcome.
• Expired connections don't announce themselves until the next run. A monthly flow can be broken for four weeks before anyone knows.
• Service account password changes and MFA enrolment break connections across an entire estate simultaneously, which looks like a platform outage and isn't.
• Concurrency collisions on the same record produce intermittent, unreproducible failures that only appear under load. They're the hardest to diagnose and the easiest to design out up front.
• On-premises data gateway outages fail everything behind them at once. Gateways go down for Windows updates, machine restarts and expired service account passwords, and none of that is visible from Power Automate.
• Adding a Terms of Use requirement in Conditional Access can break flow connections retroactively, with no change on the Power Platform side at all.
• Throttled queues don't drain themselves. Turning the flow off leaves pending cancellations stuck in Waiting until you turn it back on.

Consultant notes

• Build the runbook by failure type, not by flow. "Connection expired — here's how to repair it" is reusable; "what to do if the invoice flow fails" is not.
• Exclude dedicated flow connection owners and service accounts from Terms of Use policies as a standing recommendation. It costs nothing and prevents an ugly class of incident.
• Get gateway ownership named on day one, with a monitoring story. It's the single most common piece of unowned infrastructure in a hybrid Power Platform estate.
• Push for service principal or service account connection ownership everywhere that matters. Roughly half the incidents on this list disappear.
• Warn the client that a flow can fail silently by succeeding with bad data. That's the failure mode their monitoring won't catch and the one that reaches customers.

---

Add to this list after each incident — the patterns that matter are the ones this client keeps hitting.