Reliability and governance: flows IT will trust

The problem with a flow that fails quietly

A flow's most dangerous failure isn't a loud crash. It's the silent one. You build something useful (logging feedback, chasing approvals, posting a weekly summary) and for a while it just works, so you stop looking at it. Then one day a step fails, the flow stops, and nothing tells you. The weekly summary simply doesn't arrive. The feedback stops getting logged. Everyone assumes it's still running because it always has been, and by the time someone notices, two weeks of data are missing.

This is worse than never having automated the task, because a manual task that stops getting done is visible: someone notices the notes weren't written up. An automated task that stops is invisible until you go looking. So the first rule of a dependable flow is: it must tell you when it breaks. You should never learn about a failure from an angry colleague.

Power Automate can do this for you. You can configure failure notifications so that when a flow fails (or fails repeatedly, or hasn't succeeded in a set period), you get an email or a Teams message. Set this up on every flow that does real work, before you rely on it. A one-line alert that says "your Feedback flow has failed three times today" turns a silent two-week outage into a same-day fix.

Why connections expire

The single most common reason a working flow suddenly stops is a connection that's gone stale. A flow doesn't magically have access to your email, your files or your Teams; each connector is a signed-in link, authenticated as a particular person. That link can lapse, and when it does, the flow fails with an "unauthorised" or 401/403 error on the step that uses it.

Connections break for predictable reasons, and knowing them means you can prevent most:

• A password change. Change your Microsoft password and connections authenticated as you may need re-signing. This is the classic "it worked yesterday" failure.
• Multi-factor or session expiry. Security policies can force periodic re-authentication; a long-idle connection eventually needs renewing.
• The owner leaves. If a flow's connections are signed in as you, and you leave the company or lose the licence, the flow dies with your account. A flow that quietly depends on one person's login is fragile by design.

The fix for a lapsed connection is to re-authenticate it ("Fix connection") and resubmit the failed run, no rebuild needed. The prevention, for anything important, is not to hang a business-critical flow off one individual's personal login. Which leads straight to the questions IT will ask.

Ownership, permissions and the "bus test"

Ask of any flow that matters: if the person who built it were unavailable tomorrow, could anyone else keep it running? If the honest answer is no, the flow isn't reliable; it's a single point of failure wearing a helpful disguise.

Two things fix this. First, co-ownership: add another owner (or share it with a team) so more than one person can see its run history, fix a connection and edit it. A flow only one person can even open is a flow that breaks permanently the day they're off sick. Second, for the most important automations, organisations often move the connections off an individual and onto a service account: a shared, non-personal account owned by IT that doesn't leave when a person does and isn't subject to one individual's password changes. You usually can't set that up yourself, which is exactly why it's an IT conversation.

Permissions cut the other way too. A flow can only ever do what its connections are allowed to do; it runs as the account behind them. That's a safety limit (a flow can't reach a SharePoint site the owner can't) and a risk (a flow owned by someone with broad access can touch a lot). IT will care about this, and rightly.

What IT will actually ask

When you take a flow beyond your own desk (anything touching shared data, customers or other people's work), expect a version of these questions. Having answers ready is the difference between a quick yes and a long no.

• Who owns it, and who's the backup? One name is a red flag. They want at least two, or a team.
• What does it connect to, and as whom? Which apps, which data, signed in as which account. A flow on a personal login raises an eyebrow; a service account reassures.
• Where does data go? Especially: does anything leave the organisation, and does any personal data get copied, mailed or exposed? This is where UK GDPR and your data-protection duties bite.
• What happens when it fails? "It alerts me and I re-run it" is a good answer. "I'm not sure, it hasn't failed yet" is not.
• Does it respect our data-loss rules? Many organisations run data loss prevention policies that block certain connector combinations, say a connector that could move internal data to a personal cloud service. If your flow trips a DLP policy it simply won't run, and that's deliberate.
• Is it in the right place? Larger organisations separate flows into environments (a sandbox for building and testing, and a managed production environment for real work), so nothing half-built runs on live data. If your organisation works this way, IT will want important flows built and governed there, not in your personal default environment.

None of this is IT being obstructive. Every question maps to a real way an unsupervised automation can quietly cause harm: miss data, expire, leak, or become un-fixable. A flow that has good answers to all six is one they can say yes to quickly.

The reliability checklist

Before you leave any flow running on real work, run down this list:

• Failure notifications are switched on and go somewhere you'll see them.
• There's a second owner, or it's shared with a team.
• You know which account each connection is signed in as, and whether that's sustainable if that person leaves.
• You've handled the obvious failure paths (a missing file, an empty result, a step that might error) rather than assuming the happy path always holds.
• You know what the flow touches and whether any of it is personal or leaves the organisation.
• Someone other than you could read the run history and understand what broke.

Try it now

Common mistakes

• Assuming no news is good news. A flow with no failure alert that you haven't checked isn't "running fine"; you simply don't know. Silence is not success; set up the alert.
• Building on a personal login for shared work. A business-critical flow tied to one person's account is a countdown to the day they change their password, go on leave or leave the company. Use co-ownership and, where you can, a service account.
• Only handling the happy path. Real inputs are messy: an empty result, a missing attachment, a service briefly down. A flow that assumes everything always arrives perfectly will fail on the first day reality disagrees.
• Treating IT's questions as bureaucracy. Every governance question exists because an unsupervised flow found a new way to cause harm. Answering them well gets you a faster yes, not a slower one.
• Over-trusting a flow because it's run cleanly for months. A long clean run history breeds a dangerous confidence: you stop watching precisely when a silent failure or an expired connection would do the most damage. Reliability isn't a state a flow reaches and keeps; it's alerts, a backup owner and the occasional check that keep it dependable. The longer a flow has "just worked", the more worth confirming it still is.

Keeping current

The failure-alert options, connection behaviour, environment model and DLP controls all evolve, and larger organisations configure them differently. Microsoft's Employ robust error handling and the data loss prevention policies guidance on Microsoft Learn track the current controls. One change worth watching: Microsoft's Advanced Connector Policies (ACP), which reached general availability in June 2026, are starting to replace the classic business, non-business and blocked DLP classification with a single allowlist model, initially for certified connectors. It is off until an admin turns it on, and organisations are likely to adopt it gradually, so the DLP model described above is still what you are most likely to meet for now. The underlying principle is durable: an automation you can't see failing, can't hand over, and can't account for isn't reliable, however clever it is. Accurate as of 14 July 2026.