Power Automate will not fix your process

The platform is genuinely good. That is exactly why it will carry a bad process further than it deserves to go.

I use Power Automate constantly and I think it is genuinely good at what it does. That is precisely why I am careful with it. A capable, low-friction platform will carry a bad process much further than it deserves to go, and it will do it fast enough that nobody stops to ask whether they should.

Low-code lowers the wrong barrier

The barrier low-code removes is the build. It does nothing to the barrier that actually matters, which is understanding. Before Power Platform, a bad process was protected by the cost of automating it — someone had to justify developer time, and that justification was a filter. A weak case did not survive it.

When the build takes an afternoon, that filter disappears. The result is not fewer bad automations. It is more of them, built faster, by people with less reason to question the request.

What amplification looks like

A process with three unnecessary approvals, automated, becomes three unnecessary approvals that now fire instantly and cannot be quietly skipped when someone is on leave. The friction that used to let people work around a bad rule is gone, and the bad rule is now enforced perfectly.

I have watched a team end up worse off after an automation, not because it failed, but because it worked exactly as specified against a specification nobody had challenged.

Automation does not improve a process. It commits to it.

The sprawl problem

The second issue is what happens after eighteen months. Flows accumulate. They are built by different people, named inconsistently, owned by accounts that get disabled when someone leaves, and connected to services under personal rather than service credentials. Individually every one of them is fine. Collectively they become an estate nobody has a map of.

This is why governance is not paperwork. Naming conventions, ownership that survives a leaver, documented purpose, a defined owner for failures, and a review cycle are what stop a productive platform becoming an undocumented dependency.

How I use it now

• Map first. If I cannot draw it, I do not build it.
• Remove steps before automating the survivors.
• Build the exception path deliberately, not as an afterthought.
• Name and document it so a stranger can own it.
• Agree who gets the failure notification before it goes live.

None of this makes the platform less useful. It makes the difference between a flow that quietly does its job for years and one that becomes somebody else's problem in a quarter.