→ Next: Part 2: Approvals and escalation, building flows people actually respond to (13 Aug)
What this post covers: what a connector actually is, as distinct from a trigger; why Microsoft splits connectors into standard and premium, and what that split is actually based on; why one premium connector anywhere in a flow puts a licensing requirement on the whole flow, not just the step using it; and why the exact same-looking flow can run free for one person on your team and need a paid licence for another.
A flow is two decisions wearing one interface
Every flow you build makes two separate decisions that Power Automate presents as if they were one. The first is timing: when does this thing run. The second is scope: what is it allowed to touch. The interface hides the seam between them well enough that most people never notice they're looking at two different systems stacked on top of each other.
Triggers aren't events, they're a question your flow keeps asking covered the timing half properly: whether a trigger is polling a service on a loop or sitting registered and waiting to be pushed to. That's the mechanism behind "when X happens", and if you haven't read it, most of what follows here will land better once you have.
This post is about the half that gets skipped even by people who've internalised the trigger distinction: the connector. Every action you drag into a flow, including the trigger itself, belongs to a connector. Treating the connector as background wallpaper, the icon you pick before you get to the interesting settings, is how a flow that cost nothing last month starts needing a line item this month with no obvious cause.
What a connector actually is
A connector is Microsoft's packaged integration for one specific service. The SharePoint connector bundles every trigger and action Power Automate offers for SharePoint: "When an item is created", "Get items", "Create item", and the rest. The Outlook connector does the same for Outlook. When you search the trigger picker and pick one, you're not choosing a standalone capability, you're choosing a service and then a specific move within it.
That bundling matters because Microsoft doesn't licence individual actions. It licenses the connector as a whole, and it tags every connector with exactly one label: standard or premium. Every trigger and action inside that connector inherits the label. There's no such thing as a standard trigger sitting inside a premium connector, or the reverse.
The standard/premium split, and why it looks arbitrary
Outlook, SharePoint, Teams, OneDrive, Excel Online (Business) and Forms are standard connectors. They're folded into the Microsoft 365 licence you're already paying for, no separate line item required.
SQL Server, most Azure services, Dynamics 365, Business Central, Service Bus, and virtually every third-party connector, plus anything custom you build yourself, are premium. They sit outside the standard M365 entitlement entirely.
Nothing about the technical complexity tells you which side a connector lands on. Some standard connectors do genuinely more under the hood than some premium ones. The split is a licensing decision Microsoft makes connector by connector, not a reflection of how hard the integration was to build. The only reliable way to know is to check the connector's own listing in the maker portal before you build around it, not after.
One premium connector taxes the whole flow
Here's the mechanism that actually explains most of the "why did this suddenly cost money" surprises. The moment a single premium action appears anywhere in a flow, even buried three steps deep in a branch that rarely runs, the entire flow is classified premium. Not the one step. The whole thing, including the trigger and every standard action sitting around it.
A flow built entirely from SharePoint and Outlook actions runs free under any M365 licence. Someone comes back a month later and adds one step that queries SQL Server to enrich a record, because it was the fastest way to get the answer they needed. That flow now needs premium licensing to run at all, on every single execution, not just the runs that actually touch the SQL step. The nine standard actions around it didn't change. The classification of the whole flow did.
Per-user or per-flow, and when each one actually makes sense
There are two ways to cover a premium flow, and they solve different problems.
A per-user Premium licence attaches to a person, at roughly $15 per user per month at current Microsoft list pricing. It lets that person build and run unlimited flows using standard, premium, and custom connectors, capped at around 40,000 actions per user per day. This is the licence most people mean when they say "I need Premium".
A per-flow Process licence attaches to the automation itself, not a person, at roughly $150 per flow per month at current list pricing. This is the one that actually explains the "why does this cost me and not you" scenario. Without a per-flow licence, whether a flow can run generally depends on the licence held by its owner and the connections it uses. Build the exact same premium flow twice, once under an account with a Premium licence and once under an account without one, and the second copy simply won't run, even though the flow definition is identical. Attach a per-flow licence instead, and everyone who owns, co-owns, or triggers that specific flow can run it regardless of what licence they personally hold.
Which one makes sense depends entirely on shape. A handful of citizen developers building lots of small premium flows for their own use are usually cheaper to cover per-user. One critical premium flow that a whole department depends on, where you don't want licensing to hinge on whichever individual happens to own it, is usually cheaper and safer to cover per-flow.
Frequently Asked Questions
What actually decides whether a connector is standard or premium?
Microsoft's own classification, connector by connector, listed against each one in the maker portal. It has nothing to do with how complex the integration is under the hood. Check the listing before you build around a connector, not after you've already committed to it.
Does using a premium connector for just one action tag the entire flow as premium?
Yes. It doesn't matter how small the premium step is or how rarely that branch runs. The moment a premium connector appears anywhere in the flow, the whole flow needs premium licensing sorted, on every execution.
What's the practical difference between a per-user and a per-flow licence?
A per-user licence attaches to a person and covers everything they build. A per-flow licence attaches to one specific automation and covers everyone who owns, co-owns, or triggers it, regardless of their own licensing status.
Can two people see the exact same flow behave differently because of licensing?
Yes, and this is usually where the confusion starts. Without a per-flow licence, whether a premium flow can run generally depends on the owner's own licence and connections. An identical flow copied to an account without Premium simply won't run, even though nothing in the flow itself changed.
Does a Microsoft 365 licence include any premium connectors?
No. M365 alone gets you the standard connector set only. Anything premium, including a custom connector you build yourself, needs one of the two licence types above regardless of which other Microsoft 365 apps you're already paying for.
Is a connector I build myself automatically premium?
Effectively yes. Custom connectors are classified premium by default, so building your own integration doesn't sidestep licensing, it just moves the cost from "which service am I calling" to "I made this call possible myself".
Where the series goes from here
This series builds from the mental model outward. Each part assumes you've read the ones before it.
Part 2: Approvals and escalation, building flows people actually respond to (13 Aug) takes the trigger and connector groundwork from this post and builds the flow shape people actually need at work: an approval that reminds someone once, then escalates.
Part 3: Error handling and retry policies, failing loudly vs failing silently for three weeks (20 Aug) covers what happens when a flow hits a bad day, and how to make sure someone finds out immediately instead of three weeks later.
Part 4: Premium connectors and licensing traps, where "free" quietly stops being free (27 Aug) goes back to the standard/premium split from this post and works through the specific moment a flow that tested fine suddenly needs a licence nobody budgeted for.
Part 2 lands 13 Aug.