← Previously: Part 3: Error handling and retry policies, failing loudly vs failing silently for three weeks (20 Aug)
What this post covers: why standard and premium is a property of the connector rather than of what you are trying to do; the HTTP action, which is the single most common way a free flow stops being free; whose licence a flow actually runs under and what happens when that person changes jobs; and what the platform does when the licence is missing, which is not the clean immediate error you would want.
The flow that worked perfectly for ninety days
Someone builds a flow that reads a SQL table every morning and posts a summary to Teams. It works. It has worked since March. Nobody thinks about it again.
In July an email arrives saying the flow will be turned off. Not from IT. From the platform. The flow was built during a Power Automate trial, the trial ran its ninety days, and the SQL Server connector sitting in step two was never covered by anything else.
That is the shape of almost every licensing surprise in Power Automate. Not a wrong decision made in the open, but a correct-looking flow that quietly depended on something with a price tag, running long enough that everybody assumed it was free by default.
Part 3 was about failures that stay invisible for three weeks. This is the same failure mode wearing a different hat. The difference is that this one has an invoice attached.
The tier belongs to the connector, not to your intention
This is the piece that trips people up, so it is worth being precise about it.
Every connector in Power Automate carries a tier, and that tier is a fixed property of the connector itself. It has nothing to do with how much data you move, how often the flow runs, or how important the process is. It is a label attached to the connector by Microsoft, and it does not change because your use case is modest.
Standard covers most of what a Microsoft 365 workflow touches: SharePoint, Outlook, Teams, OneDrive, Excel Online, Planner, Forms, and the Approvals connector.
Premium covers SQL Server, Dataverse, Azure services, Salesforce, ServiceNow, SAP, DocuSign, the generic HTTP action, and every custom connector you build yourself.
The rule that follows is the one worth writing on the wall: one premium action makes the entire flow premium. Not the step. The flow. A twelve-step flow where eleven steps are SharePoint and one step is a SQL lookup is a premium flow, and it needs a licence that covers premium connectors before it will run.
The designer does tell you. Premium actions carry a premium tag next to the name in the action picker and in the flow itself. It is a small label and it is very easy to click straight past when you are hunting for the action that does the thing you need.
Approvals look premium and are not
Worth clearing up, because it comes up constantly.
Approvals store their data in Dataverse. Dataverse is premium. It would be reasonable to conclude that approval flows need a premium licence, and that conclusion is wrong.
The Approvals connector is a standard connector. The Dataverse storage underneath it is part of the service, not something you are connecting to. Any licence that gives you Power Automate with standard connectors is enough to build approval flows, and the people responding to approval requests do not need a premium licence either.
Everything in Part 2 runs on a Microsoft 365 licence. That was deliberate.
The HTTP action is where most people walk into it
If you are going to hit this trap, this is the step you hit it on.
At some point a flow needs to call an API that has no dedicated connector. You search the action list, find one called HTTP, and it does exactly what it says: any method, any URL, any body. It is the most useful action in the product and it is premium.
There are standard alternatives, but they are narrow, and knowing the boundary saves you an argument with procurement later.
Send an HTTP request to SharePoint is a standard action on the SharePoint connector. It runs SharePoint REST API calls, which covers a surprising amount of what people reach for the generic HTTP action to do: setting field values the normal actions do not expose, working with permissions, reading list metadata. It is limited to SharePoint's own REST surface, and it does not support deprecated APIs.
A handful of other standard connectors carry their own Send an HTTP request actions against a subset of Microsoft Graph endpoints, including Office 365 Users and Office 365 Groups. Same principle: they reach their own service's API and nothing beyond it.
If the endpoint you need sits outside those, the generic HTTP action is the answer and it is premium. There is no clever route around that. What you can do is check the narrow options first, because a decent share of "we need premium for this" turns out to be a SharePoint REST call that a standard action already covers.
The licence follows the owner, not the person who clicks the button
This one changes who you have to buy a licence for, so it is worth getting right.
For automated and scheduled flows, the flow runs in the context of the owner's licence. The person who dropped a file in the SharePoint library does not need anything. The flow's owner does.
For instant flows, Power Apps flows, and Dataverse-triggered flows, it runs in the context of the invoking user's licence. The person pressing the button needs the coverage.
Two consequences fall out of that, and both of them show up eventually.
The first is what happens when the owner leaves. A scheduled flow owned by someone who has changed jobs is a flow whose licence walked out with them. Reassigning ownership before an exit is a two-minute job. Discovering it three weeks later, from a report that stopped arriving, is not.
The second is multiplexing, which is Microsoft's word for using one licence to serve many people. If a premium flow sends its output back to the person who triggered it, that person is getting value from the flow and needs coverage too. If the flow moves data into a shared location that colleagues read, they are consuming the output rather than triggering the flow, and that is fine. The line sits at who set it off and who it answers.
What actually happens when the licence is missing
Not a clean error. That is the frustrating part.
A premium flow whose owner has lost premium coverage is first downgraded to reduced performance, and the owners are notified. If nothing changes, the flow is disabled after fourteen days.
At tenant level the enforcement timeline is longer still. Admins get a window measured in months to remediate before environment operations start getting restricted, and flow suspension sits further out again.
Which means the gap between "this stopped being covered" and "this stopped working" is long enough that nobody connects the two. The flow gets slower. Then it stops. Then somebody opens a ticket about the report that has not arrived, and three people spend a morning on it before anyone checks the licence.
Failing loudly beats failing slowly. That was Part 3's argument, and licensing is the place it applies hardest, because the platform's default here is to fail slowly on purpose.
Seeing the invoice coming
Three things, in the order I would do them.
Read the tier before you add the action, not after. The premium tag is in the action picker. Ten seconds of attention there is worth more than any audit later.
Run Flow checker before you save. It flags premium dependencies alongside the usual errors, and it costs nothing.
Audit what already exists. The Build It from Tuesday builds the flow that does this across your whole tenant: it walks the flows, reads each one's connections, checks the tier, and tells you which ones are sitting on a premium connector before someone in finance tells you.
On the licence itself, the decision is usually between the Power Automate Premium plan at fifteen US dollars per user per month and the Process plan at a hundred and fifty US dollars per flow per month. Those are list prices at the time of writing and your tenant may well pay something different. The shape of the decision is what matters: per-user makes sense when a handful of people each build a lot; per-flow makes sense when one automation serves a whole department and you would otherwise be licensing everybody who touches it.
Frequently Asked Questions
How do I tell if a connector is premium before I use it?
The action picker shows a premium tag next to the name, and the connector's page in Microsoft's connector reference states its tier. Microsoft also publishes a filtered list of every premium-tier connector, which is the authoritative answer when the label is ambiguous.
Does one premium action really make the whole flow premium?
Yes. There is no partial licensing. A flow that uses eleven standard actions and one premium action is a premium flow and needs premium coverage to run at all.
Do approval flows need a premium licence?
No. The Approvals connector is standard, even though approvals store their data in Dataverse. Approvers responding to a request do not need a premium licence either.
Is there a free alternative to the HTTP action?
Sometimes. Send an HTTP request to SharePoint is a standard action covering SharePoint's REST API, and a few other standard connectors expose Send an HTTP request actions against a subset of Graph endpoints for their own service. For arbitrary third-party endpoints there is no standard equivalent.
What happens to my flows if my premium trial expires?
The flow is downgraded to reduced performance first and the owners are notified. If nothing is done it is disabled after fourteen days. Tenant-level enforcement runs on a much longer timeline, which is why the eventual failure rarely gets connected back to the trial ending.
If I share a premium flow, does everyone need a licence?
It depends on the trigger and on who gets the output. Automated and scheduled flows run under the owner's licence, so people who indirectly set them off do not need coverage. Instant, Power Apps and Dataverse-triggered flows run under the invoking user's licence, so the person pressing the button does. If the flow returns something to the person who triggered it, they need coverage regardless.
Where the series goes from here
That closes Power Automate from Scratch. If you landed here first, the rest of it:
- Part 1: Triggers and connectors, the mental model nobody explains (6 Aug) - what a trigger actually is, why polling and event triggers behave differently, and the connector model this post has just charged you for.
- Part 2: Approvals and escalation, building flows people actually respond to (13 Aug) - approval actions, reminders, escalation paths, and the reason most approval flows get ignored.
- Part 3: Error handling and retry policies, failing loudly vs failing silently for three weeks (20 Aug) - Configure run after, what a retry policy will and will not retry, and how bolting on error handling can hide a real failure.
Sunday's Deep End closes the month with the honest version of what all four parts add up to: what Power Automate is genuinely for, and where handing a decision to a flow stops being automation and starts being avoidance.