Power Platform Licensing Cost Guide

Power Platform pricing confuses buyers because Microsoft sells the same four products — Power Apps, Power Automate, Power Pages, and Copilot Studio — under three fundamentally different billing models at the same time: per-user (a flat monthly seat), per-flow / Process (a flat monthly price per automation, independent of who runs it), and pay-as-you-go (metered consumption billed through your Azure subscription). The sticker price of a license ($5, $15, or $20) is the easy part. The hard part is knowing which model each workload belongs in, because picking the wrong one is where the real money leaks — a $20/user app handed to 200 occasional users, or a high-volume flow left on a per-run meter that never stops ticking.

This guide untangles all three models with the current list prices, the mechanical rules that decide which license a workload actually consumes, and the breakeven math that tells you when to move a workload from one model to another. It is deliberately complementary to our deeper walkthroughs: for the Business Central-specific entitlement picture see the Power Platform with Business Central guide, and for automation design and connector behavior see the Power Automate guide. Here we stay strictly on the money: what each model costs, what triggers it, and how to budget for it across the Microsoft Dynamics 365 family and the standalone Power Platform.

The three licensing models at a glance

Before the line items, the frame matters. Microsoft's licensing overview organizes everything around how usage is counted, not just how much it costs.

**Per-user / per-app** — What you pay for: A named person running apps/flows · How it's billed: Monthly seat (annual commit) · Predictability: High — fixed per person · Best when: Most users are daily, named, internal
**Per-flow (Process)** — What you pay for: One automation, unlimited runners · How it's billed: Monthly per flow · Predictability: High — fixed per automation · Best when: Shared/service-account flows, high-volume triggers
**Pay-as-you-go** — What you pay for: Actual consumption (runs, active users, AI credits) · How it's billed: Metered via Azure subscription · Predictability: Low — scales with usage · Best when: Spiky, unpredictable, or external-user workloads

The single most expensive mistake is treating these as interchangeable. They are not. A per-user license and a pay-as-you-go meter for the same app can produce a 10× cost difference depending on how often each user opens it. The rest of this guide is the decision logic that prevents that swing.

Per-user licensing: Power Apps and Power Automate Premium

Per-user is the model most buyers default to because it is the most predictable: you pay a flat monthly seat and the user can run as much as their plan allows. The current lineup is small.

Power Apps has two commercial per-user SKUs plus a free developer tier. The Power Apps Per App plan runs $5/user/month and lets one user run one app (across up to two environments) — the cheapest entry point for a single-purpose internal tool. Power Apps Premium runs $20/user/month and removes the one-app limit, adds premium connectors and Dataverse access, and includes a monthly AI Builder credit allowance; practitioner comparisons consistently place these two at $5 and $20 respectively as the canonical figures (scaleupally, toolradar). The free Power Apps Developer Plan is for building and testing, not production sharing.

Power Automate mirrors this. Power Automate Premium is $15/user/month and is the plan that replaced the older, more expensive per-user RPA tiers. Microsoft consolidated the lineup in 2023: the legacy "Power Automate per user with attended RPA" plan (formerly $40) became Premium at $15, and "Power Automate per flow" was renamed "Process" (plugjunction). A free, standard-connector-only Power Automate is seeded into most Microsoft 365 licenses — more on that trap below.

What a per-user license actually buys

A Premium seat is not just "the right to log in." It carries the mechanical entitlements that determine whether a workflow is free or premium:

Premium connectors. Anything beyond the standard connector set (Salesforce, SAP, custom HTTP, most third-party and on-premises data gateways) flips a flow or app from free to premium. Once a single premium connector is present, every user who runs that flow needs a premium license.
Dataverse. Premium is the gateway to Dataverse-backed apps and the relational model that serious business apps require. The licensing overview notes that Microsoft 365-seeded users get only limited Dataverse provisioning capabilities, not the full developer data capacity — so "free" M365 users cannot legitimately host a Dataverse app without a Premium seat (Microsoft Learn).
Action and request limits. Each plan carries daily/hourly API request caps. The user running the flow determines the limit tier applied — a detail that becomes important when you compare it to the Process model next.

Where per-user breaks down

Per-user is the wrong frame for three workload shapes, and recognizing them early is worth more than any discount:

Infrequent users. A monthly compliance app opened twice a year by 300 staff costs 300 × $20 = $6,000/month under per-user — for what may be a few hundred total sessions. Pay-as-you-go bills only the days those users are active, which can be a fraction of that.
Anonymous or external users. Public-facing Power Pages sites and customer portals have no "named internal user" to license. Per-user pricing has no clean answer for them.
Service-account and shared-mailbox flows. Automations triggered by a shared inbox or run by a service principal have no human to license — and licensing each possible human runner is both imprecise and expensive. That is exactly the gap the Process plan was built to close.

Per-flow / Process licensing: price the automation, not the person

The Power Automate Process plan (the renamed successor to "Power Automate per flow") inverts the per-user logic. Instead of licensing who runs the flow, you license the flow itself. Microsoft's own licensing FAQ states the rule plainly: "If a cloud flow has a Process license assigned, then it can access premium connectors, has the highest action limits, and always uses the Process license limits, regardless of who runs the flow" (Microsoft Learn).

That sentence is the entire economic case for the Process plan. Three things fall out of it:

The runner's license no longer matters. A flow licensed with Process can be triggered by a free M365 user, a service account, or a shared mailbox without anyone needing a $15 Premium seat.
Premium connectors are included for that flow. The premium-connector paywall that blocks free users simply does not apply to a Process-licensed flow.
It gets the highest action/request limits, so high-volume automations are not throttled the way user-licensed flows are.

Pricing is a flat monthly amount per flow. Practitioner breakdowns place the Process plan at roughly $150/flow/month (sometimes cited in its unattended-RPA capacity context) in the current lineup (smartprocessflow), with the legacy "per flow" plan historically around $100/flow before the 2023 consolidation.

When Process beats per-user

The decision is pure arithmetic once you know who triggers the flow:

Service-account and shared-mailbox automations. If a flow runs under a shared inbox that 40 people send to, you cannot license 40 senders. One Process license covers the flow.
High-volume event-driven flows. A flow firing on every new ticket, every inbound email, or every IoT event runs hundreds of times per day. Process gives it the highest action limits and a fixed price, so cost stops scaling with volume.
Team-owned flows with rotating owners. When ownership moves between team members, per-user licensing creates a moving target. Process licenses the artifact, not the person.

The flow-runs rule that surprises everyone

Microsoft's licensing FAQ makes a subtler point that catches teams off-guard: when a flow runs under a user license rather than a Process license, the limits and entitlements of whoever triggered it are what apply — including whether that person even has a premium license. This is why teams wake up to broken flows after a key user leaves: the flow was effectively "borrowing" one person's entitlement. Assigning a Process license to business-critical flows removes that person-dependency entirely, which is as much a resilience decision as a cost decision (Microsoft Learn).

Pay-as-you-go: metering through Azure

The third model is consumption-based and is where Power Platform most resembles a public cloud bill. With pay-as-you-go, you link a Power Platform environment to an Azure subscription, and Microsoft meters four distinct activities:

Power Apps — billed per active user, per app, per day. A user who opens an app counts once for that day, regardless of how many times they use it.
Power Automate — billed per flow run.
Power Pages — billed per monthly authenticated user and per monthly anonymous user, reflecting the external-facing nature of the product.
AI Builder — billed per unit of consumption (the credit model covered below).

The meters are defined explicitly in Microsoft's pay-as-you-go meters documentation, and they are the cleanest statement anywhere of what Power Platform actually charges for at the unit level.

The breakeven math

Pay-as-you-go is cheapest at low utilization and most expensive at high utilization, with a fairly sharp crossover. Consider an internal app used by 100 people, each opening it a different number of days per month:

Heavy use (20 days/month): under pay-as-you-go the daily meter adds up fast; 100 users × 20 days × (per-active-user-day rate) routinely exceeds 100 × $20 Premium. Here per-user wins.
Light use (2 days/month): the metered cost is roughly a tenth of the per-user cost. Pay-as-you-go wins decisively.
The crossover typically sits around one to two weeks of active use per user per month — the exact point depends on your Azure pricing, but the principle is invariant: metered beats seat-based for occasional users, and seat-based beats metered for daily users.

Microsoft itself steers high-volume flows off the meter: its pay-as-you-go documentation explicitly recommends that "any flows with a high number of runs use a Power Automate per flow plan, as that is a fixed price per month" rather than paying per run (Microsoft Learn). Read that as Microsoft telling you the per-run meter is only economical below a certain volume — above it, switch to Process.

The hidden-cost risks of metering

Pay-as-you-go has no monthly cap, which is its great strength and its main danger:

Runaway flows. A misconfigured loop or a polling trigger that fires every minute produces tens of thousands of runs and a corresponding Azure bill. The per-run meter does not ask permission.
AI consumption. AI Builder and Copilot Credits meter independently and can dominate the bill if a flow does heavy document processing, form extraction, or model inference.
No predictable ceiling. Unlike a per-user commit, the only limit is your Azure budget alerts. Set those alerts before enabling pay-as-you-go, not after.

The right use of pay-as-you-go is as a discovery model: launch a new app or flow on the meter to learn its real usage pattern, then graduate it to per-user or Process once you have data. Leaving everything on the meter permanently is how Azure bills quietly climb.

Power Pages and the external-user economics

Power Pages sits awkwardly in the per-user frame because its users are often not your employees — they are customers, partners, or anonymous visitors. Per-user licensing simply does not model a public-facing site well, which is why Power Pages leans on capacity-based add-ons and the pay-as-you-go meters described above.

The model has two consumption axes, both defined in the pay-as-you-go meters documentation:

Authenticated monthly users — named users who sign in to the site. You license these per-month, either as a capacity add-on or via the meter.
Anonymous monthly users — visitors who never sign in. These are metered separately and are the unit that matters for public marketing sites, self-service portals, and lead-capture pages.

The practical implication is that Power Pages cost should be modeled on expected monthly visitors by type, not on headcount. A customer self-service portal with 5,000 anonymous visitors and 200 authenticated customers is a very different bill from an internal-only site, and the per-user mental model will mislead you every time. For anything public-facing, start from the meter and the capacity add-ons; for anything internal and named, the per-user side may apply. If you are building portals alongside a Dynamics 365 rollout, that external-user math belongs in the same scoping exercise as the core ERP seats.

AI Builder and Copilot Credits: the new consumption layer

AI features were historically licensed through AI Builder capacity add-ons: a unit of capacity that delivered a pool of credits consumed by document processing, form extraction, sentiment analysis, and similar models. That model is in the middle of a significant transition, and any 2026 budget that ignores it will be wrong.

The current facts, from Microsoft's own documentation and practitioner tracking:

Power Automate Premium seeds 5,000 AI Builder credits per user per month. This is the "free" AI allowance that travels with the $15 seat, and Microsoft's community tracking confirms existing Premium users retain this seeded allowance through the transition window (Power Platform Community).
The AI Builder capacity add-on is roughly $500 per unit per month for ~1 million credits, per current practitioner pricing breakdowns (smartprocessflow). That is the line item you hit once the seeded 5,000 credits run out.
AI Builder credits are being replaced by Copilot Credits. Microsoft's documentation now describes Copilot Credits as "the common currency across Copilot Studio capabilities," available through pay-as-you-go meters, prepurchase plans, and Copilot Credit prepaid packs (Microsoft Learn). The standalone AI Builder capacity add-on SKU reached end-of-sale on November 1, 2025, after which overage and all new capacity must come from Copilot Credits (Power Platform Community).

What this means for budgeting

Three concrete shifts:

AI is no longer a side purchase. It is becoming the primary variable cost on the platform. A flow that extracts data from 10,000 invoices a month can burn through the seeded credits in days and then meter continuously.
The unit of measure is converging. Whether you use Copilot Studio, Power Automate AI actions, or Power Apps AI features, the consumption is consolidating onto one currency. That makes forecasting easier — once you measure it.
Plan a capacity audit before renewal. You have roughly a year from the transition to move off the old AI Builder add-ons. Teams that do not audit consumption and secure Copilot Credit budget in advance report service disruptions when both credit types deplete (Microsoft Learn).

The budgeting rule of thumb: assume any AI-heavy flow will cost its license plus a consumption line item. The license is the floor; the credits are the variable ceiling.

What is actually "free" inside Microsoft 365 and Dynamics 365

The confusion tax on Power Platform is highest around what is already included. Microsoft's licensing overview is clear that both Microsoft 365 and Dynamics 365 licenses seed a limited Power Apps and Power Automate entitlement (Microsoft Learn):

Microsoft 365-seeded Power Automate gives users standard connectors only — SharePoint, Outlook, Teams, and the other first-party M365 services. This is the "free" automation that most information workers already have.
Microsoft 365-seeded Power Apps allows apps built on M365 data sources under restricted limits, but explicitly does not include full Dataverse provisioning or premium connectors.
Dynamics 365 licenses seed Power Apps and Power Automate entitlements scoped to the Dynamics apps the user is licensed for, with the cross-application premium entitlements requiring a separate Power Platform license.

The "free" trap

The single most common licensing surprise is the premium-connector paywall. A flow that a team built "for free" inside M365 suddenly demands premium licensing the day someone adds a Salesforce, Mailchimp, HTTP, or custom API connector. At that point every user who runs the flow needs a Premium seat, a Process license on the flow, or pay-as-you-go enabled on the environment. There is no middle ground.

This is why connector classification is a first-class design concern, not a footnote: the connector set chosen at build time determines the licensing model for the life of the automation. Retrofitting a free flow to use only standard connectors is often cheaper than licensing premium for 50 users.

A decision framework: which model for which workload

With all three models on the table, the assignment rule is mechanical once you can answer three questions about each workload.

Is the user named, internal, and daily? — Per-user (Premium for apps/flows, Per App for single-purpose)
Does the flow run under a service account, shared mailbox, or at high volume? — Per-flow (Process)
Are users occasional, external, anonymous, or unpredictable? — Pay-as-you-go
Does the workload use heavy AI/document processing? — Per-user/Process as the base + Copilot Credits for consumption
Is it a public-facing site? — Power Pages capacity + per-authenticated/anonymous-user meters

The framework's value is that it forces you to separate access (who can run it) from consumption (how much it runs). Per-user and Process price access. Pay-as-you-go and Copilot Credits price consumption. Most realistic Power Platform estates need all four — applied to different workloads, not stacked on the same one.

Total-cost scenarios, worked

Three archetypes show how the models combine in practice.

Scenario A — internal daily app. 120 warehouse staff use a Power Apps inspection app all day, every day, against Dataverse. Per-user Premium is obviously correct: 120 × $20 = $2,400/month. Pay-as-you-go would bill 120 × ~20 active days and cost several times more. The Process plan does not apply because these are real named users, not a shared automation.

Scenario B — shared-inbox triage flow. A Power Automate flow monitors a shared customer inbox, classifies the email with AI Builder, and routes it. It is triggered by inbound mail, not by any one person, and runs 2,000+ times a month. Licensing each possible sender is impossible. The right answer is one Process license (~$150/month) for the flow plus a Copilot Credit allowance for the AI classification — a fixed, predictable cost that does not scale with email volume on the flow side.

Scenario C — occasional-use compliance portal. A Power Pages portal lets 4,000 staff certify their annual compliance status, logging in perhaps twice a year. Per-user pricing across 4,000 users is absurd for twice-yearly use. Pay-as-you-go on monthly authenticated users bills only the people who actually visit in a given month — a tiny fraction of 4,000 — and the cost tracks the real, lumpy usage pattern instead of peak headcount.

The pattern across all three: match the billing model to the shape of the usage, not to the type of the product. The same product (Apps, Automate, Pages) can legitimately sit in a different model depending on how it is used.

Common licensing mistakes — and how to avoid them

Most Power Platform overspend clusters around a small number of recurring errors:

Licensing infrequent users per-seat. The single biggest leak. Audit any per-user app where median monthly active days is under five — those users usually belong on pay-as-you-go.
Leaving high-volume flows on the per-run meter. Microsoft's own guidance says switch to Process for high run counts. Any flow above a few thousand runs/month is almost certainly cheaper on Process.
Letting person-licensed critical flows depend on one user. When the owner leaves, the flow's entitlement goes with them. Business-critical flows should carry their own Process license.
Forgetting the AI consumption line item. Budgeting the $15 or $20 seat and ignoring Copilot Credits guarantees a surprise Azure bill. Model AI consumption separately, always.
Treating the seeded M365 automation as "free forever." It is free until a premium connector appears. Track connector usage in every M365-seeded flow.
Renewing without re-assigning the model. Usage patterns drift. An app that started occasional may have become daily; a flow that started low-volume may now be high-volume. Re-run the decision framework at every renewal.

How to audit and right-size what you already own

If you are walking into an existing Power Platform estate, the path to a defensible cost picture is short and mechanical:

Pull the license consumption report. The Power Platform admin center exposes which users hold which plans and which environments have pay-as-you-go attached. This is your baseline.
List every flow and its trigger/owner. Flag anything owned by a shared mailbox, service account, or former employee — those are Process candidates.
Classify connectors per flow. Any flow with a premium connector is consuming premium entitlement somewhere; confirm it is covered by Process or per-user, not silently borrowing a user's license.
Measure active-day distribution per app. For each app, look at how many days each user actually opened it in the last 90 days. The distribution tells you instantly whether per-user or pay-as-you-go is cheaper.
Estimate AI consumption. Pull AI Builder / Copilot Credit usage and project it forward. This is the line item most likely to have grown since the last review.
Apply the decision framework to each workload and re-assign models where the shape has changed.

Done once a year, this audit typically surfaces 15–30% in re-assignable spend — usually in the form of per-user seats that should be pay-as-you-go, or per-run meters that should be Process. The work is unglamorous but it is the highest-ROI licensing activity available, because the savings are recurring and the models only get more complex over time.

The bottom line

Power Platform's three licensing models exist because no single billing shape fits every workload, and the cost discipline is in the assignment, not the negotiation. Per-user handles your named daily users. Process handles your shared, high-volume, and service-account automations. Pay-as-you-go handles your occasional, external, and unpredictable usage. Copilot Credits sit on top of all three as the consumption layer for AI. Get that mapping right and the per-unit prices almost take care of themselves; get it wrong and no discount will rescue the bill.