Power Apps licensing decision guide

What it does

The path from a stated requirement to a defensible licensing recommendation. The mechanics are simple — what the app touches decides whether it's premium, and premium needs an end-user entitlement — but the traps sit in what people assume their existing Microsoft 365 and Dynamics 365 licences already cover.

Key facts

Premium entitlements are triggered by capability, not by app type. Microsoft's examples are premium connectors, Dataverse tables, on-premises data gateways and custom APIs. Makers can check the current designation on the App Details page in the maker portal.
Power Apps for Microsoft 365 covers creating and running apps on Microsoft 365 data and standard connectors. It doesn't cover on-premises data, premium connectors or custom connectors.
Microsoft 365 licences can show a Dataverse service plan. That plan exists so Microsoft 365 applications like Project can store data in Dataverse. It doesn't entitle anyone to build or run custom apps, and creating a Dataverse database in a production or sandbox environment still requires a premium Power Apps or Power Automate licence.
Building a canvas app needs no licence. Building a model-driven app does. Users without a licence can access an environment and make things; they just can't play apps.
Dynamics 365 licences carry different Power Apps use rights. Where a licence has limited use rights, premium canvas apps can only be played when embedded in a model-driven app as a custom page — not standalone in a browser or the mobile player. Embedding by iframe doesn't qualify.
Per app plan capacity has to be allocated to the environment before it takes effect. Buying it isn't enough, and this generates a support call on almost every rollout.
Auto-claim policies assign a Power Apps per user licence automatically when a user launches an app that demands premium, or launches any app in a managed environment.
Trial licences expire and can be renewed three times. Microsoft's own recommendation for proofs of concept is a developer environment rather than serial trials.
Removing premium connectors from an app doesn't change its designation until you republish it. Apps grandfathered under the 2019 use-rights change keep showing as premium and keep working on Office-seeded licences.

When to use / skip

Do this analysis before the design is fixed, not after. The order that works: what data does this touch, where does it live, who runs it, how many of them, and does the client already own an entitlement for those people. Answer those five and the recommendation writes itself. Answer them in the wrong order — design first, licence later — and you get the classic outcome, where a solution built on Dataverse for good architectural reasons lands on a client who budgeted for standard connectors.

Do not attempt to quote a number. Direct the commercial conversation to the licensing guide and the client's Microsoft account team, and keep your own contribution to what the architecture requires. Consultants who volunteer prices are consultants who get quoted back at them eighteen months later.

Configuration decisions

Whether Dataverse is in scope, because that single decision makes the app premium for every user who runs it.
Which population runs the app: everyone in the tenant, one department, or a handful of specialists. That's the difference between a per-user conversation and a per-app conversation, and nobody can advise on it without a headcount.
Whether existing Dynamics 365 licences already carry the use rights you need, and whether they're the limited kind. Check per licence, not per client.
Whether managed environments are in the plan, since launching any app in a managed environment can trigger a premium entitlement under auto-claim.
Whether to run auto-claim at all. It removes friction for users and removes visibility from whoever owns the budget.
Where proof-of-concept work happens. Developer environments don't expire; trials do, three times.

Gotchas

"It's included in E3" is the single most expensive assumption in the platform. It covers standard connectors and Microsoft 365 data, and stops there.
The Dataverse service plan appearing in the Microsoft 365 admin centre convinces clients they already have Dataverse. They have a storage mechanism for Project, and nothing they can build on.
An app that uses Dataverse for Teams runs on an Office-seeded licence only when embedded in Teams. Play the same app standalone and the user gets a trial prompt. Teams-first pilots hit this exactly at the point they succeed.
Per app passes sitting unallocated in the tenant look, to everyone involved, like licences that should be working.
The licensing guide is a PDF that changes. Any number you memorise has a shelf life, and Microsoft defers most of the detail to it deliberately.
Building being free means makers accumulate apps nobody can run. The cost lands at go-live, which is the worst possible moment to discover it.

Consultant notes

Put the five questions in the discovery pack and get them answered in writing. A licensing surprise at UAT is a commercial conversation with your name on it.
Say plainly that architecture drives licensing here. If the client needs relational data, row-level security and offline, they need Dataverse, and Dataverse is premium. Trying to design around the licence usually produces something worse and more expensive to own.
Get the client's account team into the room early. They have current numbers and the authority to commit to them; you have neither.
Watch for the SharePoint-to-avoid-licensing decision. It's legitimate when the data really is a small flat list, and a deferral dressed as a saving when it isn't.
Recheck app designations after every significant change. The publish-to-update behaviour means the portal can be telling you about last month's architecture.

Recheck against the current licensing guide before any commercial conversation — the mechanics are stable, the detail isn't