Updated August 2026 Added a section on how AI agents change the failure mode of undefined processes, and tightened the argument that process work and build work run in parallel, not in sequence.
I came across a post from the Zapier blog about process improvement a while back, and it made a familiar point: most broken work is not actually broken work, it is a broken process behind it. Messy handoffs, unclear ownership, approvals that live in one person’s head. Good framing. But it treats process improvement before automation as something you do once, upfront, like a checklist item you tick and move past. In enterprise Power Platform work, that assumption is where things go wrong.
What Building Automations Teaches You About How Work Actually Flows
When you sit down to build a flow, you have to make the process machine-readable. Every branch needs a condition. Every input needs a defined type. Every approval needs an owner. Every exception needs a path.
Most processes handed over for automation have none of that. What they have instead is a document someone wrote two years ago, a few spreadsheets nobody fully trusts, and a senior colleague who holds the real logic in their head and has been doing it long enough that they no longer notice the decisions they make.
The automation developer ends up being the first person to interrogate the process at that level of detail. Not by choice. The flow will not build until the ambiguity is resolved. You cannot write a condition on a field that sometimes exists and sometimes does not. You cannot route an approval to a role when the role changes based on factors nobody documented.
This is not a Power Platform problem. I keep seeing it in every serious automation effort, both internally and from people I talk to at other orgs. The tool just makes the gaps visible faster than any process workshop does.
The Specific Process Failures That Surface When You Try to Automate
There are a few categories I keep running into.
Unclear ownership. A task gets triggered, but nobody agreed who acts on it. The automation sends an email. Nobody responds. The flow sits waiting. Eventually it times out. Everyone blames the automation.
Inconsistent inputs. The data coming in does not conform to any standard. Fields are free text where they should be choices. Dates arrive in three formats. Required fields are blank because the upstream system never enforced them. Your flow handles the clean case fine and breaks silently on everything else. Microsoft’s own guidance on error handling in Power Automate is good, but no amount of try-catch scopes will save you if nobody agreed what valid input looks like in the first place.
Approval logic nobody can fully articulate. You ask who approves a request above a certain threshold. You get three different answers from three different people. All of them are confident. Automate the majority answer and you will eventually automate the wrong one for someone’s edge case, and that person will be senior enough that it becomes your problem.
Exception handling that lives in tribal knowledge. The manual process survives because a human notices something feels off and picks up the phone. The automated process has no equivalent. The exception just propagates.
AI Agents Do Not Fix This. They Hide It Better.
This is the part that changed since I first wrote this post. In 2026 the default answer to a messy process is increasingly “put an agent on it.” I build Copilot Studio agents as part of my day job, and I ran into this internally more than once this year.
A classic flow fails loudly when the process is undefined. It errors, it times out, it dead-ends. Annoying, but honest.
An agent improvises. Give it a vague process and vague instructions and it will produce a confident answer anyway. It will route the request somewhere. It will summarize the exception instead of escalating it. The undefined process does not surface as a failure. It surfaces as plausible-looking output that nobody validates until something downstream is wrong.
So the old rule got sharper, not weaker. Automating a bad process with a flow makes it fail faster. Automating a bad process with an agent makes it fail quietly. The second one is worse. If your process has ambiguity a human would resolve with judgment, you either encode that judgment as explicit instructions and guardrails, or you keep a human in the loop at that exact point. There is no third option where the model just figures out your org chart.
Why Fixing the Process First Does Not Mean Waiting to Build
The standard advice is to fix the process before you automate it. The advice is correct and almost never followed, because the people who own the process feel no urgency until they see the automation breaking. The broken automation is what creates the pressure to fix the underlying problem.
That does not mean automate bad processes and hope. It means process improvement and automation are parallel work, not sequential steps. You build, you find the gap, you surface it to the right person, you agree on a rule, you build the rule into the flow. Then you find the next gap.
The first build is a diagnostic as much as a delivery. You are not just producing a flow. You are producing a map of where the process is genuinely undefined. That map beats most process workshops, because it came from the requirement to actually execute the logic rather than describe it at a whiteboard.
The risk is treating that diagnostic build as the final product. It is not. The flow that handles the happy path and ignores edge cases is a prototype that revealed the real work. Ship it as final and you have automated the ambiguity along with the process.
What I Actually Do Now
My working loop, refined over the last couple of years of doing this full time:
First, build the happy path fast and label it a prototype out loud, in writing, to everyone who will see it run.
Second, log every ambiguity the build surfaces as a named decision with a named owner. Not “data quality issues.” One line per gap: this field, this branch, this approver, who decides.
Third, refuse to encode a guess. If three people give three answers on an approval rule, the flow routes to a human until one answer wins. Same for agents, just stricter.
Fourth, treat the second build as the real delivery. That is the one with the agreed rules, the exception paths, and the error handling that fails loudly instead of silently.
It is slower than pretending the process document was accurate. It is much faster than rebuilding after the automation fails in front of the wrong person. If you have run this loop differently, I would genuinely like to hear it. Find me on LinkedIn.