Don't automate a process that is about to change, that nobody owns, that runs twice a year, or that is broken. Automation makes a process faster and more consistent. It does not make a bad process good — it makes it bad at scale, silently, forever.
So the honest answer to "should we automate this?" is often "not yet", and sometimes "no". This post sets out the four cases where the answer is no, what to do instead, and a short test you can run in a meeting before anyone opens Power Automate.
Why saying no matters
Every flow you build is something you now own. It needs an owner, a service account, someone who understands it when it breaks, and a review when the systems around it change. A 50–500 person business can comfortably run dozens of well-chosen flows. It struggles when half of them were built for processes that no longer exist or never worked.
The cost of a bad automation is rarely the build. It is the eighteen months afterwards: the exceptions handled by email because the flow cannot cope, the staff who stop trusting the system, and the flow nobody dares switch off because nobody knows what depends on it.
The four cases where the answer is no
| Case | What it looks like | Do this instead |
|---|---|---|
| The process is about to change | System replacement next quarter, a restructure under way | Wait, or write a checklist to bridge the gap |
| Nobody owns it | Three teams each run part of it; no one can make a call on exceptions | Name an owner first |
| It runs twice a year | End-of-year tasks, annual reviews, occasional audits | A written checklist and a calendar reminder |
| The process itself is broken | Extra approval steps added because nobody trusts an earlier one | Fix the chain, then automate the fixed version |
The process is about to change
If the system it depends on is being replaced next quarter, or the team is restructuring, wait. Automating a process on its way out is the most expensive kind of throwaway work.
The common version: a finance system migration is planned, and someone wants to automate invoice approvals in the old system "to tide us over". The flow gets built against fields, statuses and connectors that will all change. Bridge the gap with a written procedure instead, and design the automation for the new system once its shape is known.
Nobody owns it
If you cannot name the person who decides how this process works, you cannot automate it — because every exception becomes an unanswerable question mid-build. Find the owner first.
You can usually spot this in the first workshop. Ask "what happens when the approver is on leave?" and watch three people give three answers. That is not a technical problem, and no amount of building fixes it. One name, with the authority to decide, has to come before the first flow. Who owns the build covers the difference between owning the process and owning the technology.
It runs twice a year
A process that runs twice a year and takes an hour costs you two hours annually. Automating it costs thousands and creates a flow nobody remembers exists when it breaks eighteen months later. Write a checklist instead.
Frequency is the multiplier on every saving. The same half-hour of effort means something very different depending on how often it happens.
Example inputs: twice a year at 1 hour; weekly at 30 minutes over 50 weeks; daily at 15 minutes over 230 working days.
The daily task is the one worth looking at, even though each run looks trivial. The twice-yearly one is the one people most want to automate, because it is memorable and painful — and it is the worst candidate on the chart. If you want to run your own numbers, the calculator does the multiplication for you.
The process itself is broken
If the approval chain has five steps because nobody trusts step two, automation cements that mistrust into software. Fix the chain, then automate the fixed version.
Broken processes show up as workarounds: the spreadsheet kept "just in case", the second approver added after one bad purchase five years ago, the email someone sends to check that the system actually did the thing. Automate that and you get a flow with five steps, a spreadsheet beside it, and an email checking the flow.
- 01Request submittedthrough a new form
- 02Routed automaticallyto five approvers in turn
- 03Approver two rubber-stampshas never rejected one
- 04Approver four re-checksbecause nobody trusts approver two
- 05Shadow spreadsheet keptin case the flow gets it wrong
The automation here is technically fine. The process is not. A 20-minute audit of your approval process shows you how to find the rubber-stamp steps before you build around them.
The test
Before building anything, answer these four questions. They take ten minutes in a meeting and save the wrong build.
- Will this process still exist, in roughly this shape, in two years?
- Who owns it?
- How many times a week does it run?
- If we did nothing else, could we just delete a step?
Question four is the one people skip. Removing a step is free and instant. Automating it is neither.
- 01Still here in two years?if no, wait or write a checklist
- 02Named owner?if no, find one before scoping
- 03Runs weekly or more?if no, a checklist usually wins
- 04Can we delete a step?if yes, delete it and re-run the test
- 05Automate what is leftnow you are building something worth keeping
What to do instead of automating
Saying no to a flow is not saying no to improvement. Each of the four cases has a cheaper fix.
- Write it down. A one-page procedure with a named owner solves more process problems than most flows. The write the process before you automate it template is a good starting point either way.
- Delete a step. Turn approvals that never reject anything into notifications. Stop collecting fields nobody reads.
- Use a checklist and a reminder. For low-frequency tasks, a SharePoint page with a checklist and a recurring calendar entry is often all you need.
- Change the template. A better form or a shared document with the right headings often removes the retyping people wanted automated.
When the answer is yes
The opposite of each case is a good sign. A process that is stable, owned, frequent and already lean is exactly what automation is for. Approvals that run weekly, collection tasks with a clear deadline, compliance reminders with fixed dates, and handoffs between two teams that currently happen by email are all strong candidates.
- It will still exist, in roughly this shape, in two years
- One person can decide how exceptions are handled
- It runs at least weekly
- Every step has been questioned, and the useless ones removed
- Two people describe it the same way
- You know how many times it ran last month
"Not yet" is not "never"
Most of the processes that fail the test today pass it within a few months. The system replacement finishes, the restructure settles, an owner gets named, a step gets deleted. Keep a short list of the processes you said no to and why, and revisit it each quarter. That list is often the best source of your next good automation, because the hard thinking has already been done.
What to do next
Take the process you were about to automate and run the four questions with whoever owns it. If it fails one, fix that first — it is usually cheaper than any build. If it passes all four, you have a good candidate, and the next step is writing it on one page.
The best automation project frequently starts by deleting two steps and automating the third.
Want the version for your business?
Work out what manual processes are costing you — three minutes, no contact details needed.
Work out the cost