Dormant flows: the automations nobody drives any more

The dangerous automation is not the one that breaks. It is the one that nobody has thought about in eighteen months, still holds a service account, and would break something if you switched it off, and nobody can tell you what.

A flow has no end date. It is built for a project, the project ships, the project closes, and the flow keeps its trigger. It does not report that its reason for existing has gone. It just runs, or waits, and stays on the list.

Dormant is not the same as broken

Three states get confused, and they need different answers.

Failing. The flow runs and errors. Visible, at least in principle. The platform records it.

Dormant. The flow is enabled, has a valid trigger, and has not run in a long time. Nothing is wrong. Nothing is happening either.

Orphaned. The flow runs perfectly, and its owner left the company. This is the worst of the three, because everything looks fine.

A flow can be dormant and orphaned at once, which is the combination worth hunting first.

Why a sleeping flow is not free

The instinct is to leave them alone: they run rarely, so they cost nothing. Three reasons that is wrong.

It holds a connection. A dormant flow keeps an authenticated connection to SharePoint, a CRM, a mailbox. That connection is a live credential attached to a process nobody supervises. When it is a personal account rather than a service account (which it often is, because the flow was built quickly), it is also a credential that will break the day that person leaves, in a way nobody will diagnose.

It occupies a seat. Depending on the licensing plan, a disabled or dormant flow still counts. You are paying for the option of running it.

It will wake up. This is the one people underestimate. A flow dormant for a year because its trigger folder was empty will fire the day someone drops a file in that folder. It will then run 2024 logic against 2026 data, and it will do it silently.

How to find them, concretely

The signal is not “has not run recently”. That flags legitimate quarterly and annual flows and buries you in false positives.

The useful signal is a combination:

• No run in 60 days: the starting filter, nothing more.
• No modification in 12 months: a flow still being maintained is a flow someone still cares about.
• Its author no longer has an active account: the strongest single signal, and the easiest to check.
• Its trigger references something that no longer exists: a deleted list, a decommissioned mailbox, a closed project’s folder.

One of these means very little. Three together means the flow has almost certainly outlived its purpose.

The question to ask about each one

Once you have the list, the temptation is to switch everything off at once. Do not. The failure mode of that approach is discovering in November that the flow you disabled in September was the one producing a report the finance team quietly depends on.

For each flow, one question in this order:

1. What does it do, in one sentence? If nobody in the room can answer, that is the finding. Write the sentence down before doing anything else. You are documenting an estate that had no documentation.

2. Who would notice if it stopped? Not “who owns it”: that is often nobody. Who receives its output, reads its file, gets its email.

3. Is that person still here, and do they still need it? This is one message. Send it.

4. Then decide. Keep and assign an owner, or turn off and archive.

The archive matters. Deleting a flow deletes the only remaining description of a business process. Disable it, export the definition, keep it somewhere. Storage is cheaper than reconstructing a process from memory.

Assigning an owner is the actual fix

Finding dormant flows is a cleanup. Preventing them is a rule, and it is a simple one: no flow in production without a named owner and a named backup.

The backup is not a formality. The single-owner model fails at exactly the moment you need it, when that person leaves, changes team, or is on holiday during the incident. Two names is the difference between “we will look into it” and “we called Nadia”.

Give each flow, at minimum:

• A name a non-technical reader can understand. Not Flow_v3_FINAL.
• One sentence describing what it does and why it exists.
• An owner and a backup, both currently employed.
• A review date. Even annual. A flow that nobody has revisited in a year is a flow on its way to being dormant.

The uncomfortable part

Doing this properly means admitting that a fair number of your automations should not exist. That is not a failure of the team that built them: they were right when they were built. Circumstances moved, and nothing in the tooling noticed.

That is exactly the gap. Platforms are very good at running flows and completely indifferent to whether a flow still deserves to run. Nothing in Power Automate, n8n or Make will ever tell you that a flow’s project ended two years ago, because none of them knows what a project is.

Someone has to look. The only question is whether it happens on a schedule, or the week after something goes wrong.