The Licensing Model Decision That Determines Your Cost by a Factor of Four
Power Apps Per-App licensing costs $3.50–$4.50/user/app/month at enterprise EA rates. Power Apps Per-User licensing costs $14–$18/user/month. For a user who accesses a single application, the per-user licence is 4x the cost of the per-app licence. For a user who accesses five applications, the per-app cost is 5x more expensive than per-user. The licensing model decision is not nuanced — it is an arithmetic calculation based on one variable: how many Power Apps applications does each user access?
What makes this decision routinely wrong in enterprise deployments is that most organisations do not segment their user populations when purchasing Power Apps. They select either Per-User for the entire estate (overpaying significantly for single-app populations) or Per-App and then discover that their power users and business analysts are running into licence barriers when they access additional applications. The correct approach is a hybrid model — Per-User for developers and multi-app users, Per-App for functional populations accessing a specific operational tool — and this requires governance discipline to maintain accurately as the app portfolio grows.
Per-App Plan: Mechanics and Entitlements
The Power Apps Per-App Plan licenses a single user to access a single application — either a canvas app or a model-driven app. The per-app licence includes Dataverse access scoped to that specific application, meaning the user can read and write to Dataverse tables accessed by the licensed app. It does not include rights to access other Power Apps applications, and it does not include rights to access Dataverse data outside the scope of the specific app.
One important clarification: "one app" under the Per-App plan means one application, which can include multiple screens, forms, and workflows within that application boundary. A complex multi-screen field service application that includes incident management, parts ordering, and route planning is a single application for licensing purposes. The licence boundary is the Power Apps application object, not the number of features or screens within it.
Per-App allocation mechanics
Under the Per-App plan, licences are allocated at the environment level, not the user level, in the Power Platform Admin Centre. When a user is assigned a Per-App allocation for a specific environment, they can access all apps shared with them in that environment — not just a single designated app. This is a common misunderstanding: "per app" in the pricing model means per-app units purchased; the actual allocation grants access to all apps in the environment for that user. For organisations with multiple separate apps in a single environment, this creates a technical mismatch between the pricing model intent and the actual permission boundary.
The practical implication: if you have 200 users who access a single HR app and you purchase 200 Per-App licences, and then a new Expense Reporting app is deployed in the same environment and shared with those same 200 users — those users now technically have access to two apps under one Per-App licence. This is a grey area in Microsoft's enforcement, but the conservative compliance position is to purchase an additional Per-App allocation per user per additional app in scope. Given the risk of audit findings in this area, we recommend maintaining separate environments for separate app populations to avoid this ambiguity.
Per-User Plan: Mechanics and Entitlements
The Power Apps Per-User Plan grants a single user unlimited access to all Power Apps applications — canvas and model-driven — across all environments within the tenant. It includes full Dataverse access (not scoped to specific apps), plus access to AI Builder credits (approximately 500 AI Builder session credits per user per month), plus access to premium connectors within Power Apps.
Per-User is the correct plan for: business analysts building multiple apps; IT developers maintaining the Power Apps estate; departmental super users who access 3+ operational apps; and users who need to move fluidly between applications in a multi-app workflow. At $14–$18/month at EA rates, Per-User becomes cost-effective at 4+ apps per user versus the Per-App plan at $4/app/user/month.
M365 licence interaction
Microsoft 365 E3 and E5 licences include a restricted Power Apps capability — users can build and run canvas apps that connect exclusively to M365 data sources (SharePoint, OneDrive, Teams, Outlook, Excel Online). This M365 seeded right does not include Dataverse access, model-driven apps, or premium connectors. For many departmental use cases — automating SharePoint list workflows, building Teams-embedded data collection forms, digitising Excel-based processes — the M365 seeded right is sufficient and no additional Power Apps licence is required.
The compliance failure mode is building M365-style apps that initially connect to SharePoint, then expanding them to connect to Dataverse or a SQL backend as requirements grow. The moment a premium connector is added or the app reads from Dataverse, the M365 seeded right is insufficient and a Per-App or Per-User licence is required for all users of that app. This architectural boundary must be enforced as a governance rule, not left to individual developer judgement.
Pay-As-You-Go: When It Makes Sense
Power Apps Pay-As-You-Go is billed at $10/unique authenticated user/app/month, charged through an Azure subscription. "Unique" means each distinct user who accesses the app at least once in the billing month. The billing model counts unique users, not sessions — a user who logs in 50 times in a month is billed once at $10.
PAYG is more expensive than Per-App for any sustained usage: $10 PAYG vs $4 Per-App at EA rates is a 2.5x premium for the same functionality. The cases where PAYG makes commercial sense are narrow: genuinely seasonal deployments (an annual compliance certification app used by all 5,000 employees for two weeks), project-based tools with an uncertain user count, or pilot deployments where you are validating user adoption before committing to EA licensing. For any app with consistent monthly users, PAYG is the wrong commercial model and should be converted to Per-App or Per-User.
| Scenario | Monthly Users | Per-App Cost/yr | Per-User Cost/yr | PAYG Cost/yr | Best Choice |
|---|---|---|---|---|---|
| Single-app deployment | 500 users | $24,000 | $96,000 | $60,000 | Per-App |
| 2 apps per user | 500 users | $48,000 | $96,000 | $120,000 | Per-App |
| 4 apps per user (break-even) | 500 users | $96,000 | $96,000 | $240,000 | Either |
| 5+ apps per user | 500 users | $120,000+ | $96,000 | $300,000+ | Per-User |
| Seasonal (2 months/year) | 1,000 seasonal | $48,000 (annual) | $192,000 | $20,000 | PAYG |
Dataverse and Model-Driven Apps: Licence Requirements
Model-driven apps — apps built on a Dataverse data model, with forms, views, and relationship navigation built by the platform — require either a Per-App or Per-User licence. The M365 seeded right does not cover model-driven apps under any circumstances. This is a categorical requirement, not a volume or usage threshold. If your Power Apps deployment includes model-driven apps, every user accessing those apps needs a dedicated Power Apps licence.
Dataverse storage is included in both Per-App and Per-User plans, but at different scopes. Per-App includes Dataverse access for the specific app. Per-User includes full Dataverse access across all tables the user has permissions to reach. This distinction matters when users are administrators or developers who need to access raw Dataverse data outside an application context — those users need Per-User, not Per-App, regardless of how many apps they access.
Audit Risk: Common Power Apps Compliance Failures
The four most common Power Apps audit findings, in order of frequency and financial exposure, are: M365-seeded apps accessing Dataverse without a dedicated licence; model-driven app access without Per-App or Per-User licences; Per-App environment misconfiguration granting access to multiple apps; and PAYG environments with consistent monthly users who should be on committed licensing.
The Dataverse compliance failure is the highest-exposure item. In a typical enterprise with 200–400 Power Apps users, finding 30–50 model-driven app users without dedicated licences is common in unmanaged environments. At $4/user/app/month Per-App, the annual under-licensing exposure for 40 users on 2 model-driven apps is $3,840/year — modest at small scale, but in large organisations with hundreds of Power Apps and thousands of users, the aggregate exposure grows quickly. Microsoft's SAM engagements specifically target Dataverse usage data to identify unlicensed model-driven app access.
EA Negotiation Tactics for Power Apps
Power Apps licensing sits within the Microsoft EA as part of the Power Platform product family. At EA renewal, the commercial positions that generate real savings for Power Apps are: model restructuring (Per-User to Per-App where the deployment pattern supports it), deployment-based scope negotiation, and growth commitment packaging.
Challenge the model recommendation with deployment data
Before accepting Microsoft's account team Power Apps recommendation, build your deployment data: how many users are active, how many apps per user on average, and how many apps are in your environment inventory. Microsoft's default recommendation is Per-User for all users — it simplifies their licensing conversation and maximises their per-user revenue. If your analysis shows that 70% of your Power Apps users access a single application, the Per-App model for that segment saves 75% of that population's licence cost versus Per-User. Present the data, not a preference.
Use app count growth as a commitment signal
If you have a documented Power Apps growth roadmap — a citizen developer programme, a specific number of apps planned for production within the EA term — use that commitment to negotiate a volume tier improvement on Per-App pricing. Microsoft's standard EA Per-App pricing is applied at a volume tier based on total seats. Committing to deploying 10 apps used by 500 users each = 5,000 seat-apps of Per-App volume, which may qualify for a lower tier rate than your current Per-App allocation. The negotiation mechanism is the same as for any EA product: volume commitment in exchange for improved unit economics.
For the complete Power Platform licensing context — including Power Automate, Power BI, and Power Pages — see the Power Platform Licensing Complete Guide. For Power Automate licensing decisions, see Power Automate Licensing: Standard vs Premium Flows. For EA negotiation mechanics that apply to all Microsoft products including Power Platform, see the Microsoft EA Negotiation Complete Guide. For understanding true-up implications of Power Apps usage growth, see the True-Up Compliance Guide.