Power Platform Licensing: What I Wish Someone Told Me on Day One

I’ve seen a project budget blow up by six figures because nobody checked licensing during solution design. The app worked great. It used a premium connector. 400 users needed access. Nobody did the math until procurement got the quote.

Licensing isn’t something you figure out at the end. It’s an architecture constraint that shapes how you build.

The Mental Model

Power Platform licensing comes down to three questions:

1. What are you building? (Power Apps, Power Automate, Power Pages, or a combination)
2. Who needs access? (how many users, internal vs. external)
3. What connectors do you need? (standard vs. premium)

The answer to #3 is what catches most people.

The Three License Tiers

Seeded (Included)

If your organization has Microsoft 365 or Dynamics 365 licenses, users already have limited Power Platform rights. They can run apps that use standard connectors and basic Dataverse operations within the context of their existing license.

The catch: seeded rights are limited. The moment you add a premium connector, custom connectors, or use Dataverse as a standalone data store (not just within D365), you need a dedicated license.

When this works: Simple apps that read/write to SharePoint, send emails via Outlook, or extend existing Dynamics 365 functionality using only standard connectors.

Per-App

Users get access to a specific app (or a set of apps within an environment). Check the official licensing guide for current pricing.

When this works: You have a focused app used by a specific group. 50 warehouse workers using one inventory app. 20 HR staff using one onboarding app. The per-app cost is lower than per-user when people only need one or two apps.

Per-User

Users get access to unlimited apps within the tenant. Check the official licensing guide for current pricing.

When this works: Power users who access multiple apps. Your 15 operations staff who use 4 different apps across multiple environments. Per-user becomes cheaper than per-app somewhere around the 3-4 app mark per user — do the math for your specific situation.

The Premium Connector Trap

This is where most licensing mistakes happen. An app that uses only standard connectors can run under M365 seeded rights. The moment you add one premium connector, every user of that app needs a Power Apps per-app or per-user license.

The most common surprise premiums:

• Dataverse — if you’re using Dataverse as your app’s data store (not just within Dynamics 365), that’s premium
• HTTP connector — the generic HTTP action in Power Automate is premium
• Custom connectors — any connector you build yourself is premium
• Dataverse (legacy) — the old Common Data Service connector, also premium
• Azure SQL — premium
• All AI Builder actions — premium

How to check before you build: In Power Apps studio, look at the connectors panel. Premium connectors have a diamond icon. In Power Automate, it’s the same indicator. Check this on day one of the project, not during UAT.

The workaround trap: I’ve seen teams try to avoid premium licensing by routing data through a non-premium path — like writing to SharePoint instead of Dataverse, then syncing with Power Automate. This usually creates a worse architecture AND may still require premium licenses if the flow itself uses premium connectors. Build the right solution and budget for the right license.

Real Scenarios

”50 users need a simple approval app on SharePoint”

If the app reads/writes to SharePoint and sends emails via Outlook, these are standard connectors. Users with M365 E3/E5 licenses can run this app under their seeded rights. No additional Power Apps license needed.

”10 power users managing Dataverse records”

Dataverse is premium. Each user needs a per-app license (if they’re using just this one app) or a per-user license (if they use multiple apps). For 10 users on one app, per-app is likely cheaper.

”500 users need to view data, 20 need to edit”

This is common and expensive if you don’t plan carefully. Options:

• Model-driven app with appropriate security roles — all 500 users need licenses, but read-only users can get per-app licenses while editors get per-user. Check current license tiers for read vs. write distinctions.
• Power Pages for the 500 viewers — Power Pages has its own licensing model based on page views or authenticated users. This can be dramatically cheaper for view-only scenarios.
• Power BI for view-only — if the 500 users just need to see reports and dashboards, Power BI has its own (separate) licensing that may be more cost-effective.

Don’t give 500 people Power Apps licenses to view data that could be a Power BI dashboard.

”External users accessing a portal”

External users = Power Pages. It has a per-authenticated-user model and a capacity-based model. This is fundamentally different from Power Apps licensing. Don’t try to give external users internal Power Apps licenses — it doesn’t work architecturally and the cost model is wrong.

Dataverse Capacity

Dataverse storage is billed separately from user licenses. There are three buckets:

Database capacity — your table data. Rows, columns, the actual business data. This is the one that grows fastest.

File capacity — attachments, notes with files, image columns. Large but usually cheaper per GB.

Log capacity — audit logs, plugin trace logs. Grows silently in the background and surprises people.

Every tenant gets a base allocation with their licenses, and additional capacity is purchased separately. The base allocation is often smaller than people expect.

How to estimate: Look at your current data volumes. A Dataverse row is roughly 1-2 KB for a typical business record. 100,000 accounts with 20 columns = roughly 150-200 MB. That’s not much. What gets you is attachments (file capacity) and audit logs you forgot to configure retention policies for (log capacity).

What to watch: Go to Power Platform admin center → Resources → Capacity. Set up alerts before you hit the limit. Running out of capacity doesn’t immediately break things, but you’ll get warnings, and eventually new record creation will be blocked.

Power Automate Licensing

Power Automate has its own licensing layer:

Per-user plan — one user gets unlimited flow runs (with fair use limits). Good for individual power users building their own automations.

Per-flow plan — a single flow runs unlimited times regardless of how many users trigger it. Good for shared business processes that multiple people use. Each flow needs its own license.

The common mistake: Building a flow that’s triggered by many users (like an approval process) on a per-user license — which only covers the flow owner’s runs. If 50 users trigger it, you either need 50 per-user licenses or one per-flow license for that specific flow. The per-flow license is almost always cheaper for shared processes.

RPA (desktop flows): Attended and unattended desktop flows have separate license add-ons. Unattended is significantly more expensive because it requires dedicated machine capacity. Budget for this early if your solution includes desktop automation.

The Architect’s Pre-Project Checklist

Before writing a single line of code or creating your first app, answer these:

1. What connectors will the solution use? List every data source and integration. Flag any premium connectors. This determines whether seeded rights are enough or dedicated licenses are needed.

2. How many users, and what do they do? Separate creators/editors from viewers. Count users who need the app daily vs. occasionally. This drives the per-app vs. per-user decision.

3. Is Dataverse the right data store? Dataverse triggers premium licensing. If your app only needs a simple list, SharePoint might be good enough (and free with M365). Don’t use Dataverse just because it’s there — use it because you need relational data, security roles, or platform features that SharePoint can’t provide.

4. What’s the expected data volume? Estimate rows, attachments, and audit log growth over 2 years. Compare against your tenant’s included capacity. Budget for overages.

5. Are there external users? External = Power Pages, not Power Apps. Different licensing model entirely.

6. Will Power Automate flows be shared? Shared flows = per-flow licensing. Personal automations = per-user licensing.

7. Does the solution need AI Builder? AI Builder consumes credits on a capacity model — separate from user licenses. Budget this explicitly.

Run through this list during solution design, not during deployment. It takes 30 minutes and can save months of procurement headaches.

Common Mistakes

Building on premium connectors without telling the client. The app works in dev (where the developer has a per-user license). It goes to UAT with 5 testers (5 licenses, no big deal). Then it goes to production with 400 users and someone finally does the multiplication.

Using per-user when per-app saves money. For a single-purpose app used by 200 people, per-app is almost always cheaper than per-user. Per-user only wins when users need multiple apps.

Forgetting Dataverse capacity in project estimates. User licenses and capacity are separate costs. A project can be “licensed for users” but blocked because the environment hit its storage limit.

Not checking connector types during design. It takes 10 seconds to check if a connector is premium. Do it before you build the flow, not after.

Ignoring Power Automate licensing for shared flows. The flow works when the developer tests it. It breaks (or incurs unexpected costs) when 100 users trigger it, because only the developer has a license.

For the latest pricing and tier details, always check the official Power Platform Licensing Guide — Microsoft updates it quarterly and the specifics change more often than you’d expect.