Two of the flows I built should not exist
Two of the automations I approved and built between 2021 and 2024 should never have been started, and both passed the review we were running at the time. That review asked whether anyone could describe the process end to end and whether the platform could do it. Both answers were yes. Nobody asked whether the process would still look the same in eighteen months, and in both cases it did not.
Automation pays for itself on work that is high volume, stable and unambiguous. Take one of those away and you have bought a permanent maintenance obligation in exchange for savings that were never large. If you sign off on these requests for a living, much of the value you add sits in the ones you send back.
What a request has to clear before it is worth building
Volume is the easy one to check and the one people skip. A process that runs four hundred times a month absorbs a bad week of maintenance without anyone noticing. One that runs four times a year cannot, because that same maintenance lands on a build saving an afternoon a quarter. Ask for the run count from the person who does the work.
Stability is about the rules underneath the process rather than the process itself. Ask what changed in the last two years: the approval thresholds, the cost centre list, the file finance drops in, the field sales operations renamed. If something changes every year, the build is no longer a one-time cost. You are signing up for an annual editing job with no budget line and no owner.
Ambiguity does the quietest damage. Every process has a step where a person decides, and inside a flow that step becomes a condition with a fixed threshold. Two years later nobody remembers the reasoning, the threshold still fires, and the exceptions people used to make by hand have become policy that nobody agreed to.
The quarterly flow nobody remembered between runs
The worst one I built was a quarterly rebate submission at a building products distributor. Each quarter a pricing analyst pulled two reports, matched about sixty supplier claims against shipment records and assembled a submission pack. It took her most of an afternoon. She mentioned it in a workshop, I agreed it looked repetitive, and I spent roughly twenty hours building it in Power Automate over a SharePoint list.
It ran cleanly twice. The third quarter it failed because someone in finance renamed a column during a template tidy-up, and the run sat in a failed state for nine days before anyone looked. The fourth quarter the service account hit a new password rotation policy. Both times the analyst did the work by hand while I repaired the flow.
The arithmetic never recovered. Four runs a year saving an afternoon each, against twenty hours of build and two repairs that cost me a day apiece. Nothing that runs four times a year stays in anyone's head, so no human ever noticed the silence. We turned it off in 2024 and she went back to her afternoon.
Approval routing that carries a copy of the org chart
The second pattern shows up in approval routing. Someone builds a rule that sends a request to the requester's manager unless the amount clears a threshold, in which case it goes to the regional director, with a fallback for the two cost centres that report oddly. It works the day it ships. Then the company reorganises, and every branch points at a structure that has stopped existing.
The decay is polite and hard to see. Requests route to a manager who moved, approvals land with someone who has no context, and people work around it by emailing the approver directly. I have watched the same drift in routing rules that stopped matching the sales organisation and in HR interfaces that needed a design able to survive the next reorg.
The tell is simple. If the automation holds a copy of something that lives elsewhere and changes on its own schedule, it will drift out of date. Either read that structure from the system that owns it at run time, or name the person who edits the flow every year before you approve it.
When the exception branch outgrows the happy path
The third pattern grows rather than arrives. A fulfilment flow ships with four steps. Someone adds a branch for contractors, then one for two sites with a different asset naming convention, then one for requests raised on behalf of a colleague, then one for the weeks when the cost centre list is locked. Two years on there are eleven conditions around four steps of real work.
By then the flow encodes a process nobody can describe in a meeting, and the only person who understands it is whoever touched it last. Maintenance cost has stopped tracking the value of the work and started tracking the number of special cases. Ask at that point whether a written checklist with three judgement points beats eleven branches no one can test.
The same shape turns up in the small build that goes long. A five minute manual task becomes a twenty hour build, a connector that needs a licence review, a service account somebody owns, and a fixture in every upgrade test pass from here on. The build cost sits in the project plan. The running cost appears nowhere, which is how ownership debt builds up across a tenant.
Consistency is the honest argument on the other side
The strongest case against all of this is that people skip steps. They skip them at quarter end, they skip them when the person who knows the process is on leave, and they skip them when a step feels optional. Automation does the same thing every time and leaves a record an auditor can read. That argument is real.
Weigh it by separating enforcement from execution. Enforcement can be a required field that blocks a submission, a mandatory task on the case, or a weekly report listing everything missing a signature. Those cost a fraction of a build and they fail loudly, because a blank field sits in front of a human. Execution means the system does the work, and execution carries the maintenance bill.
So when a request arrives framed as a control, ask what evidence the control has to produce and who reads it. Often the real requirement is a report showing what was skipped, which somebody builds in an afternoon and which survives the next process change.
Ask how often the rules change and who notices when it stops
Four questions sort most of the requests that reach my desk. How many times a month does this run, counted rather than guessed. How many times did the rules underneath it change in the last two years. Who notices within one working day when it silently stops. And what happens if it does not run for a week.
The last two get asked least and matter most. When nobody can name the person who notices, the automation will fail quietly and the business will absorb the damage without connecting it to the flow. That is the gap that opens when automation owners lose the thread after a failed run, and the cheapest hour to close it is the hour before approval. Asking those four questions every week is most of what a working low-code governance model does.
Pull the list of automations your team approved two years ago and sort it by runs in the last quarter. Everything at the bottom is something you are still paying for, and most of it was approved by someone who never asked how often the rules underneath would change.
