---
title: "A month of building flows: what Power Automate is actually for, and what it quietly isn't"
date: 2026-08-30T00:00:00Z
updated: 2026-09-11T11:47:29Z
tags: ["Power Automate", "Automation", "Judgment", "Citizen Development", "Licensing", "Governance", "Troubleshooting"]
canonical: https://bianca.codes/blog/what-power-automate-is-actually-for/
---

# A month of building flows: what Power Automate is actually for, and what it quietly isn't

_Four weeks of approvals, retries, triggers and licensing traps. Every flow that worked did the same thing: it moved a decision, it never made one. The boundary, and how to test for it._

Someone in a planning meeting this month said "can't we just automate that?" about a process that involved three people reading an email and deciding whether the number in it looked wrong. Everyone nodded. It got written on a whiteboard as an action item with my name next to it.

I have spent the last four weeks building flows more or less continuously. Approval chains with escalation. A trigger that kept firing twice until I found the setting that stopped it. A flow that quietly flags a premium connector before it lands on someone else's invoice. A retry policy that turned a three-week silent failure into a message that arrives the same afternoon. By any reasonable measure it was a productive month, and the whiteboard action item is still sitting there, unbuilt, because it is not a Power Automate problem.

That gap is the interesting thing. Not the flows that worked. The line between the things Power Automate absorbed without complaint and the things it kept handing back, and how consistently that line landed in the same place every single time.

## The first thing that changed was what I thought a trigger was

I opened the month writing that [triggers aren't events, they're a question your flow keeps asking](/blog/triggers-arent-events-theyre-a-question-your-flow-keeps-asking/), and I expected that to be a framing device. It turned out to be the load-bearing idea for everything after it.

A trigger is a polling question with a schedule and a memory. "Has an item been modified since the last time I checked?" The flow is not being notified of a thing happening in the world. It is asking a system a question on a loop and acting on the answer. Once that lands, a whole category of confusion resolves itself: why the flow fired twice, why it fired an hour late, why it fired on a change nobody made, why it did not fire at all on the one change that mattered.

That is also the first hint at the boundary. A question that a system can answer is automatable. "Has this row changed?" is answerable. "Is this number wrong?" is not a question SharePoint can answer. It is a question a person answers by knowing what the number usually looks like.

[Part 1 of the series](/blog/power-automate-from-scratch-part-1-triggers-and-connectors-the-mental-model-nobody-explains/) spent most of its length on triggers and connectors for exactly this reason. The connector list is the list of systems you are allowed to ask questions of, and the trigger is the question. Everything downstream is bookkeeping.

## Every flow I built was moving a decision, not making one

Here is the pattern I did not expect to be so absolute.

The approval flow in [Part 2](/blog/power-automate-from-scratch-part-2-approvals-and-escalation-building-flows-people-actually-respond-to/) does not approve anything. It finds the person who approves things, asks them, waits, reminds them, and escalates after forty-eight hours if they do not answer. Every one of those steps is transport. The approval itself happens in a human's head, and the flow's entire job is to make sure that head gets the question at the right time with the right context attached.

The premium connector flow does not decide whether a premium connector is acceptable. It notices one is about to be used and puts that fact in front of someone who has an opinion about the licensing budget. Transport again.

The escalation logic looks like judgment and isn't. "After forty-eight hours, send it to the manager" is not the flow deciding that forty-eight hours is too long. It is the flow executing a decision somebody already made, in a meeting, before the flow existed. The flow is the memory of that decision, running on a timer.

Once I noticed this I went back through everything I had built in August and could not find a counterexample. Not one flow made a call. Every flow carried a call from where it was made to where it needed to be acted on, and did it faster and more reliably than a person forwarding an email would have.

That is not a limitation. That is the product working correctly. Moving decisions between systems and people, on time, with the context intact, is a genuinely hard problem and Power Automate is very good at it. The trouble starts when someone looks at a flow doing that well and concludes the flow is thinking.

## The failures were never the logic, they were the silence

The single most useful thing I wrote all month was probably the shortest: [add a Compose action before anything complex](/blog/add-a-compose-action-before-anything-complex/). Three minutes of work, and it turns an expression that fails mysteriously into an expression whose input you can actually look at.

That post exists because of the pattern in [Part 3](/blog/power-automate-from-scratch-part-3-error-handling-and-retry-policies-failing-loudly-vs-failing-silently-for-three-weeks/). Flows do not usually break loudly. They break in a way where the run history shows green, the output is empty, and nobody finds out for three weeks because the thing the flow was supposed to produce was something nobody looked at daily. A retry policy that swallows a failure and reports success is worse than no flow at all, because now there is a system everyone trusts and a gap nobody can see.

The [single point of failure post](/blog/your-power-automate-flow-is-a-single-point-of-failure/) made the same argument from the other side: you have never tested what happens when the flow isn't there. Neither had I, on most of mine.

**Failing loudly is a design decision, not a default.** Power Automate's defaults are optimised for a flow that keeps running. Four retries, exponential backoff, then a quiet failure logged somewhere you are not looking. That is the right default for a transient network blip and the wrong default for a connector that has been unauthorised since someone's password reset. The difference between those two cases is judgment, and the platform cannot make it for you. You configure it in advance or you find out in three weeks.

## The licensing trap is a judgment problem wearing a billing problem's clothes

[Part 4](/blog/power-automate-from-scratch-part-4-premium-connectors-and-licensing-traps-where-free-quietly-stops-being-free/) covers where "free" quietly stops being free, and the mechanics are genuinely fiddly. But the mechanics are not really the problem.

The problem is that the moment where a flow crosses from included to premium is invisible at design time and expensive at scale time. Nothing warns you in a way that feels like a warning. You drag in a connector, it works, the flow ships, and eleven months later somebody in finance is reading a line item and asking who authorised it.

I built [a flow that flags premium connectors before they land on someone else's invoice](/blog/flag-premium-connectors-power-automate/), which sounds like solving the problem and is really just applying the same pattern again. The flow does not decide whether the premium connector is worth the money. It surfaces the fact, to a person, before the money is spent. Transport, one more time.

This is where the affection-with-criticism sits for me. Microsoft built a platform where the most consequential architectural decision a citizen developer makes is presented as a slightly different coloured icon in a picker. That is a product choice, and it is a bad one, and the tools are still worth using. Both things are true.

## What Power Automate quietly isn't

Four weeks in, here is the honest list.

**It isn't a decision engine.** It executes decisions. If nobody has made the decision, the flow either encodes a guess or asks a person. There is no third option, and a flow full of nested conditions is usually somebody's guess wearing a lot of branches.

**It isn't a system of record.** A flow's run history is not an audit trail. It expires, it is scoped to the flow, and it answers "what did this flow do" rather than "what happened to this invoice". If the answer to "where did this number come from" is "I think a flow did it", the record lives nowhere.

**It isn't an integration platform, at the scale people use it as one.** It is superb glue between systems that already have connectors and a modest volume of things to say to each other. When the volume climbs or the transformations get genuinely complex, you are building an integration layer in a tool that was designed for something adjacent, and the seams show as throttling, expressions nobody can read, and a maintenance surface only one person understands.

**It isn't owned by anyone by default.** The [ownership post](/blog/who-owns-the-flow-you-built-two-years-ago/) was the most uncomfortable one to write because I recognised too much of it. Flows accumulate under individual accounts, work perfectly for two years, and then someone leaves. The platform does not solve this. It does not even nudge you about it.

**And it isn't a substitute for the conversation that should have happened first.** The whiteboard action item from the top of this post is still unbuilt because "does this number look wrong" is a question three experienced people answer using knowledge that has never been written down. You cannot automate the transport of a decision that nobody has articulated. You can only automate it after somebody does the hard part, which is saying out loud what the rule actually is. At which point, frequently, you discover the rule is "it depends" and the honest answer is that this stays manual.

## The way to think about it

Next time someone asks whether Power Automate can do a thing, do not evaluate the thing. Evaluate the sentence.

Ask them to state the rule as a sentence that starts with "when" and ends with something a system could verify. "When an item in this list changes status to Submitted, send it to the person named in the Approver column." That is a flow, and it will take you an afternoon. If the sentence needs a "usually" or a "someone should check" or an "it depends on the context", you have not found a flow. You have found a decision that nobody has made yet, and building automation around it just distributes the ambiguity faster.

That test has cost me nothing and saved me two builds this month alone. Both times the conversation that followed was more useful than the flow would have been.

The tools are for connecting decisions between systems. The judgment stays where it was. A month of building flows did not move that line even slightly, and the flows that worked best were the ones that never tried to.

## Frequently Asked Questions

### **Isn't this just saying Power Automate is only good for simple things?**

No. The approval chain with reminders and forty-eight hour escalation is not simple, and neither is a flow that reconciles data across three systems with proper error handling. The distinction is not complexity, it is judgment. A flow can be architecturally sophisticated and still be pure transport. What it cannot do is decide something nobody has decided.

### **What about AI Builder and Copilot actions inside a flow? Don't those make decisions?**

They make predictions, and a prediction is a decision only if you have decided in advance what to do with it. An AI Builder sentiment score is a number; the flow still needs a threshold, and somebody has to choose the threshold. That choice is the judgment, and it happens outside the flow. AI moves the boundary a little. It does not remove it.

### **My organisation uses Power Automate for large-scale integration and it works fine. Is that wrong?**

Not necessarily wrong, but worth auditing. The question is not whether it works today, it is what happens when the person who built it leaves and the volume doubles. If the answer involves someone reverse-engineering nested expressions from a run history, the tool has been stretched past its comfortable range. Logic Apps, or an actual integration platform, exists for that shape of problem.

### **How do I know if a flow I have already built is encoding a guess?**

Count the conditions. If a flow has more than three or four branches and you cannot state each branch's rule as a sentence a colleague would agree with, the branches are probably accumulated guesses rather than an articulated policy. Write the sentences out. The ones you cannot finish are the ones to take back to a person.

### **Does this mean I should not automate anything that involves judgment at all?**

The opposite. Automate everything around the judgment. Get the right information to the right person at the right moment with the context attached, then get out of the way. That is where nearly all the value in this platform sits, and it is a much larger surface than most people use.

### **What is the single highest-value thing to fix in flows I already have?**

Make them fail loudly. Go through your existing flows and check what happens on failure, specifically whether anyone finds out. Most citizen-developed flows have no failure path at all, and a flow that fails silently is a liability disguised as an asset.