The Wednesday afternoon ritual at the old job was a finance analyst opening four spreadsheets in sequence, copying three numbers from each into a fifth, eyeballing whether the totals looked sensible, and emailing the result to leadership. Twenty minutes a week. The first time I watched it, my brain did the thing every automation-minded brain does: this could be a flow. Source data lives in known files. Output is a known format. Recipients are stable. Obvious candidate.
Six months later, after the flow had been built and broken and rebuilt twice, the analyst was back to doing it by hand. Not because the automation didn't work. It mostly worked. It kept getting things subtly wrong on the days when something about the source data was off, and the analyst's eyeballs had been the part doing the checking. When that part got automated away, the small wrongness graduated to medium wrongness, which graduated to a wrong number going to leadership, which graduated to the flow being switched off and the spreadsheet exercise quietly resuming.
The mistake wasn't building the flow. It was assuming the work was the copy-paste, when the work was the judgement call sitting inside the eyeball check. That kind of mistake is hard to notice in advance, because automation has a halo around it. If something can be automated, it feels like it should be. The cost of finding out otherwise is paid by the next person who has to debug the flow, or by leadership reading the wrong number.
What automation is actually good at
Automation does well on tasks that are repeatable, stable, and structurally similar every time. Move this file from A to B. Send a notification when this thing happens. Reformat this export and write it to that location. The defining feature of these tasks isn't that they're boring, although they often are. It's that the right answer is the same answer every time, given the same inputs, and the inputs are predictable.
When all three conditions hold, automation is genuinely transformative. The time it saves compounds, the errors it eliminates are the kind humans make when bored, and the documentation of the flow becomes the documentation of the process. There's no useful argument against automating this kind of work. It's where Power Automate earns its keep.
The trouble is that not every task that looks like this kind of task actually is.
Where the automation bias kicks in
The bias has a name in the literature: automation bias. The short version is that humans tend to over-trust automated systems once they're running. The version that matters here is that the bias kicks in twice. Once when deciding whether to build the automation, and again when deciding whether to keep relying on it.
The first decision gets framed as "if I can save twenty minutes a week, why wouldn't I." That framing is incomplete in two ways. It counts the minutes the human spends on the task but not the minutes the human spends thinking while doing it, and for some tasks the thinking is the entire point. And it counts the cost of doing the task by hand but not the cost of maintaining the automation. Flows break. Source schemas change. Connector authentication expires. The maintenance bill is real, monthly, and absent from the original ROI calculation.
The second decision is quieter. Once a flow is running, nobody asks "should this still be running?" The flow becomes part of the furniture. There's a post from 26 April on this exact failure mode, a flow had been emailing a weekly file to a manager who left the company two months earlier, and nobody noticed because the flow was working as designed.
The three categories of work that shouldn't be automated, even though they could be
Most cases where a flow turned out to be a mistake fall into one of three shapes.
Work where judgement is doing the load-bearing.
The finance analyst's Wednesday ritual is the cleanest example. The visible work was data movement. The invisible work was a human looking at the numbers and going "that doesn't look right." Automate the visible part, the invisible part disappears, and you find out about it the next time the invisible part would have caught something. Spreadsheet reconciliations, budget-vs-actual reviews, approval routing on small dollar amounts, exception triage in support tickets, all share this shape. The motion looks mechanical. The motion is dressing around a judgement call. The test is whether a knowledgeable human would notice if the output were subtly wrong. If yes, that human is part of the process, and automating around them removes the check.
Work where edge cases are rare but high cost.
A flow can handle the 95% case fluently and still be the wrong tool if the 5% case is something a human needed to catch. Customer onboarding is a common one. The standard path is automatable. The case where the billing address is in a different country to the company's tax registration is the one where a human pulls in the legal team. If the automation doesn't know to escalate that case, it slips through and nobody hears about it until the audit. The cost of the rare event is what matters, not the rate. This category catches a lot of "AI-powered triage" projects too. AI is fluent on the common case. The common case is the part that didn't need help.
Work that doesn't happen often enough to pay back the build.
The cost of maintaining a flow is roughly fixed. The benefit scales with how often the flow runs. A flow that fires daily and saves five minutes per run pays itself back inside a quarter. A flow that fires twice a year and saves an hour per run will never pay back the original build, the maintenance bill, or the cost of relearning how it works the next time it breaks. A useful question: will the next person to encounter this flow, three years from now, know enough about it to fix it? If the answer is "probably not," the automation has accrued a future debt that isn't on anyone's balance sheet today.
The decision to automate is itself a design decision
Automating something is the same kind of decision as building any other tool. It commits a future maintainer. It changes who notices when things go wrong. It transforms the process from "a person does this" to "a system does this, and a person watches the system, sometimes." Each of those changes has costs that don't appear in the time-saved calculation.
Once the decision is framed that way, the question stops being "can this be automated" and starts being "should this be a flow, a partial flow, a documented manual process, or a human deciding when to escalate." Most things land cleanly in one of those four buckets. Trouble starts when something in the bottom three gets force-fit into the top one because it looked like it fit.
Some processes get better if you deliberately don't automate them, even when you can. The Wednesday ritual at the old job ended up partially automated: the data movement stayed in a Power Automate desktop flow that consolidated the four files in the background, but the eyeball check stayed manual, and the final send-to-leadership step was a button the analyst pressed once they'd looked at the numbers. The Build It on 25 May walks through what that kind of partial flow looks like in practice.
The way to think about it
Automation isn't a default. It's a choice. The right choice for a lot of work, but a wrong choice for a non-trivial slice of it, and the slice where it's wrong gets bigger when nobody asks the question. The shift from "this could be a flow" to "should this be a flow, and at what scope" is small in syntax and large in outcome. Most of the time, parts of a process want to be automated and parts don't. The interesting work is figuring out where the seam runs.
Frequently Asked Questions
How do I know when a process is too judgement-heavy to automate?
Ask what a knowledgeable human would notice while doing it. If they'd spot anomalies, escalate weird cases, or flag a number that looks off based on context they hold in their head, those moments are the actual product of the process. The visible task is the wrapper around them. If automation removes those moments, the output gets worse, often invisibly. The fix is to keep the human in the loop for the judgement and automate the surrounding mechanics, not the other way round.
What's the difference between automation bias and automation distrust?
Automation bias is over-trusting an automated system once it's running. Distrust is the opposite, refusing to use the system even when it would help. Both fail. The middle ground is calibrated trust, which means treating the automation as a tool with known failure modes and watching for those modes specifically. Maintenance reviews, periodic spot-checks of the output, and a clear escalation path when something looks wrong are what calibrated trust looks like in practice.
Should I automate a process that only runs occasionally?
Usually no, unless the occasional run has high stakes or is hard to do correctly under time pressure. The frequency math rarely works for low-cadence flows. A better pattern for occasional work is a documented checklist with the steps and a script or template that gets pulled out and used by hand. Documentation pays back faster than automation when the cadence is low.
What if my organisation has KPIs around automating processes?
This is where the bad-flow tax accrues fastest. KPIs that count flows-built or hours-saved without weighting maintenance cost or failure-mode rate produce exactly the failure pattern this post describes. If you can't change the KPI, the local move is to keep a parallel list of flows that were built, deprecated, or failed, with the reasons attached. Six months of that list is the conversation that changes the KPI.
How do I retire an automation that isn't paying back its maintenance cost?
Quietly, but with a record. Switch it off, document why, archive the flow rather than deleting it, and put a pointer in place so the next person looking for "the X report" finds out where it went. The flow that gets ripped out without that pointer becomes the ghost everyone is afraid to delete the next time. Leaving a trail makes the retirement a normal organisational motion rather than a guilty one.
