Microsoft Power Apps licensing — metrics, traps, and Dataverse maths.

Per App vs Per User — and why both bite.

Power Apps offers two paid licences plus a set of seeded rights that come with Microsoft 365, Dynamics 365 and Power Automate. The paid SKUs are Power Apps Per App (per user, per app) and Power Apps Per User (per user, unlimited apps). The seeded rights are what most customers operate on for the first two years — until a premium-connector or custom-table requirement forces a flip to paid SKUs, and the licensing position resets.

Per App licence — what's in scope

Power Apps Per App licenses a single user against a single canvas or model-driven app, with the right to use up to two custom apps in that licence. The app itself is the contractual boundary — moving a flow into a second app, or splitting an app into modules, can trigger an additional Per App licence requirement. Microsoft's standard contract language treats the app boundary as the customer's interpretation; in audit, that interpretation is challenged against the published Licensing Guide, which is updated approximately twice a year.

Per User licence — and the premium-connector reality

Per User licences a single user against unlimited apps but with the same restriction on Dataverse premium capacity. Premium connectors (Salesforce, SAP, Oracle, SQL on-premises, custom connectors via data gateway) require Per User or Per App licensing; standard connectors (M365, SharePoint, Outlook, Excel) are seeded with the underlying M365 licence. The audit risk is users on seeded rights who are using premium connectors — a configuration that does not block them at run-time but accrues backlog licence exposure.

Where the model actually costs money.

Dataverse capacity — database, file, log

Each Power Apps tenant has a base Dataverse capacity allocation that scales with paid Power Apps licences: 250MB of database per Per User licence, 2GB per Per App licence (per user). Files (attachments) and Logs (auditing, change tracking) are allocated separately at different rates. Customers building data-heavy applications routinely consume the full database allocation within 18-24 months, and the additional capacity SKUs price at $40-50/GB/month — an order-of-magnitude markup over Azure SQL.

AI Builder credits and Copilot Studio

AI Builder credits are a separate currency required for OCR, prediction and form-processing flows. The credits are allocated against paid Power Apps and Power Automate licences at a base rate and consumed at a published per-call rate. Copilot Studio (the rebranded Power Virtual Agents) carries its own session-based metric — and the metric was repriced upward twice in 2024-2025. Customers running AI Builder or Copilot Studio at any scale should benchmark prevailing per-call costs before committing to multi-year terms.

The M365 and Dynamics 365 overlap.

Microsoft seeds Power Apps usage rights into Microsoft 365 and Dynamics 365 licences. M365 E3 and E5 include the right to build and use Power Apps against standard connectors within the M365 data boundary. Dynamics 365 licences include the right to build apps against the Dynamics 365 data within the licensed scope. The seeded rights have boundaries — premium connectors, external Dataverse tables, custom APIs — that are not enforced at run-time. Users hit those boundaries at the moment of usage; the licensing exposure accrues silently.

The seeded-to-paid migration trap

The most common audit finding we see on Power Apps is users who began on seeded rights and progressively moved into premium-connector workloads as their applications matured. The audit position is back-billed paid licences for the months the user was operating premium without a paid licence; Microsoft's negotiable position is the forward-licence and a partial back-bill. The defence is proactive licence-mode reporting through the Power Platform admin centre, not after-the-fact reconciliation.

What Microsoft watches in a Power Platform audit.

Microsoft's audit posture on Power Platform is shifting. Through 2022-2023 audits focused on overall M365 compliance with Power Apps as a secondary check. From 2024 onward, premium-connector usage in tenants without corresponding paid Power Apps licences has become a primary audit trigger. The data is visible to Microsoft through telemetry — buyers cannot opt out of telemetry without losing supportability — and audit notice typically arrives 6-9 months after a usage inflection.

1. Premium-connector usage in seeded tenants. The single most common Power Platform audit finding.
2. Dataverse capacity over-utilization. Capacity overage that has been resolved by partial app cleanup but never licence-true-upped.
3. AI Builder credit overage. Credit consumption past the bundled allocation, monetised at the per-credit add-on rate.
4. Multi-environment sprawl. Production-grade applications running in non-production environments licensed at developer pricing.
5. External user access. Apps shared with guest users — each of whom requires either Power Apps Per App Plan or Power Pages licensing.

What to push at Power Apps renewal.

Power Apps is rarely negotiated as a stand-alone line on a Microsoft EA — it sits inside the broader Microsoft commercial conversation. The leverage on Power Apps specifically tends to be on the per-environment commitment, the Dataverse capacity allocation, and the seeded-rights enforcement. In our experience across 340+ engagements, the customers who treat Power Platform as a discrete commercial item — not a sub-line on a 365 deal — capture 25-40% more savings. Disciplined software license optimization across the Power Platform estate is what converts seeded-rights sprawl back into a defensible, lower-cost position.

1. Per Environment Plan. For development-heavy estates, the Per Environment SKU can replace dozens of Per User licences at lower TCO.
2. Dataverse capacity pooling. Negotiating capacity pooling across environments avoids the per-environment minimum.
3. AI Builder credit floor. A negotiated floor on AI Builder credit pricing for the contract term protects against mid-term reprice.
4. Premium-connector seeding. Negotiating a defined premium-connector exception for specific use cases, time-bound to a transition period.
5. Audit waiver scoped to Power Platform. A narrow audit waiver covering Power Apps environments during the contract term, in exchange for a structured Power Platform commitment.