Microsoft’s Power Platform — Power Apps, Power Automate, Power BI, and Copilot Studio — has become the dominant low-code/no-code platform in enterprise IT, enabling business users to build applications, automate workflows, analyse data, and deploy AI agents without traditional development resources. But the licensing model is among the most complex and misunderstood in the entire Microsoft ecosystem. Seeded entitlements bundled within Microsoft 365 and Dynamics 365 licences create an illusion of “free” access that evaporates the moment a user touches a premium connector or exceeds a usage threshold. Standalone Power Platform licences come in per-user and per-app flavours with radically different cost implications. AI Builder credits, Dataverse capacity, and premium connector access generate hidden costs that surface months after deployment. And the Enterprise Agreement — the primary licensing vehicle for large organisations — offers bundling, volume pricing, and negotiation opportunities that most procurement teams never leverage because they do not understand how the pieces fit together. This guide decodes Power Platform licensing within the EA, quantifies the most common over-spending patterns, and provides actionable strategies for reducing costs by 20–40% while maintaining full user access.
Power Platform licensing is uniquely challenging because it operates on two layers simultaneously. The first layer is seeded entitlements — limited Power Platform capabilities included within Microsoft 365 and Dynamics 365 licences that the organisation already owns. The second layer is standalone licensing — dedicated Power Apps, Power Automate, Power BI, and Copilot Studio subscriptions that unlock full capabilities, premium connectors, and higher usage thresholds. The boundary between these two layers is where most organisations over-spend, either by purchasing standalone licences for users whose seeded entitlements are sufficient, or by failing to purchase standalone licences for users who have silently exceeded their seeded limits.
The Enterprise Agreement is the optimal vehicle for managing this complexity because it provides volume pricing on standalone Power Platform licences, bundling opportunities that reduce per-unit costs, centralised management of seeded and standalone entitlements across the organisation, and — critically — negotiation leverage during EA renewals to secure custom Power Platform pricing that is not available through CSP or MCA channels. Organisations that negotiate Power Platform as part of their broader EA strategy consistently achieve 20–40% lower costs than those that purchase Power Platform reactively in response to individual business unit requests.
The low-code application development platform. Power Apps enables business users and citizen developers to build custom applications that connect to organisational data sources (SharePoint, SQL Server, Dataverse, SAP, Salesforce, and hundreds of other connectors). Seeded access in M365 allows basic apps using standard connectors and SharePoint data. Standalone licensing is required for premium connectors (Dataverse, SQL Server, HTTP, custom connectors), on-premises data gateways, and enterprise-grade governance. Two standalone models: per-app (~USD 5/user/app/month) and per-user (~USD 20/user/month for unlimited apps).
The workflow automation platform. Power Automate enables users to build automated workflows (flows) that connect applications, synchronise data, and automate business processes. Seeded access in M365 allows basic cloud flows with standard connectors. Standalone licensing is required for premium connectors, attended and unattended robotic process automation (RPA), AI Builder actions, and process mining. Standalone models: per-user (~USD 15/user/month for cloud flows), per-user with attended RPA (~USD 40/user/month), unattended RPA add-on (~USD 150/bot/month), and process-based licensing for organisation-wide scenarios.
The analytics and business intelligence platform. Power BI licensing operates independently from the rest of Power Platform but is frequently bundled within EA negotiations. Pro is included in M365 E5; all other plans include only Power BI Free. Standalone Pro (~USD 10/user/month), Premium Per User (~USD 20/user/month), and Premium capacity (~USD 5,000+/month) provide progressively greater capability. See our dedicated Power BI Licensing Guide for comprehensive tier comparison.
The AI agent and chatbot platform (formerly Power Virtual Agents). Copilot Studio enables organisations to build AI-powered conversational agents that interact with customers and employees. Limited seeded access may be included in certain M365 Copilot entitlements. Standalone licensing is based on messages consumed (~USD 200/month for 25,000 messages, with additional message packs available). Copilot Studio is the newest and fastest-growing Power Platform component, and its licensing model is still evolving — making EA negotiations the optimal time to lock in favourable pricing.
The single most important concept in Power Platform licensing is the distinction between seeded entitlements and standalone licences. Misunderstanding this boundary is the root cause of most Power Platform over-spending and under-licensing.
| Capability | Seeded in M365 | Seeded in D365 | Requires Standalone |
|---|---|---|---|
| Power Apps with standard connectors | ✅ Basic apps, SharePoint/Excel/Teams data | ✅ Within D365 context | Not required for basic scenarios |
| Power Apps with premium connectors | ❌ | ✅ Within D365 context | ✅ Per-app or per-user plan |
| Power Apps using Dataverse | ❌ | ✅ Limited capacity | ✅ Per-app or per-user plan |
| Power Apps with custom connectors | ❌ | ✅ Within D365 context | ✅ Per-app or per-user plan |
| Power Apps with on-premises gateway | ❌ | ❌ | ✅ Per-app or per-user plan |
| Power Automate cloud flows (standard) | ✅ Basic flows, limited runs | ✅ Within D365 context | Not required for basic scenarios |
| Power Automate with premium connectors | ❌ | ✅ Within D365 context | ✅ Per-user plan |
| Power Automate attended RPA | ❌ | ❌ | ✅ Per-user with attended RPA |
| Power Automate unattended RPA | ❌ | ❌ | ✅ Unattended RPA add-on |
| AI Builder credits | ❌ | Pooled capacity (limited) | ✅ Add-on capacity packs |
| Copilot Studio messages | Limited in M365 Copilot | Limited capacity | ✅ Message packs |
Every Microsoft 365 E1, E3, E5, F1, F3, and Business plan includes seeded Power Platform entitlements. These entitlements allow users to create basic Power Apps that read and write data to SharePoint, Excel, and Microsoft 365 services using standard connectors only. Users can build basic Power Automate cloud flows triggered by M365 events (new email, new SharePoint item, Teams messages) using standard connectors with limited daily run capacity. The moment a user connects to a premium data source (SQL Server, Dataverse, SAP, Salesforce, HTTP endpoints, or any custom connector), the seeded entitlement is insufficient and a standalone licence is required.
Dynamics 365 licences include significantly broader Power Platform seeded entitlements than M365 — but only within the context of extending the D365 application. D365 users can build Power Apps and Power Automate flows that use premium connectors when those flows and apps connect to Dataverse tables used by the D365 application. This “within D365 context” restriction is critical: a D365 Sales user can build a Power App that extends their sales workflow, but if the same user builds a Power App for an unrelated HR process, that app requires a standalone licence. The contextual boundary is poorly documented and frequently misunderstood, creating compliance risk.
Standalone Power Platform licences are required whenever usage exceeds seeded entitlements. The most common triggers are premium connector usage (connecting to SQL Server, Dataverse, SAP, Salesforce, HTTP, or custom APIs), on-premises data gateway connections, Dataverse storage beyond included capacity, RPA (attended or unattended desktop automation), AI Builder model consumption, Copilot Studio message volumes, and any Power Apps or Power Automate deployment outside the D365 application context for D365 users. Standalone licences are available per-user (unlimited usage) or per-app (specific app access) — the optimal model depends on usage breadth.
Premium connectors are the single largest source of unexpected Power Platform costs. Microsoft classifies data connectors into two categories: standard connectors (included in seeded entitlements) and premium connectors (requiring standalone licensing). The classification is not intuitive, and many connectors that organisations consider basic business requirements are classified as premium.
SharePoint, Excel Online, Outlook 365, Microsoft Teams, OneDrive, Planner, To Do, Approvals, Office 365 Users, Office 365 Groups, Notifications, and other Microsoft first-party cloud services. Standard connectors also include a limited set of third-party connectors such as Twitter/X, RSS, and some basic social media integrations. Any Power App or Power Automate flow that uses only standard connectors is covered by the seeded M365 entitlement — no standalone licence required.
Dataverse, SQL Server, Azure SQL, Oracle Database, SAP, Salesforce, ServiceNow, HTTP (REST API calls), custom connectors (any API the organisation builds or integrates), Azure Blob Storage, Azure Service Bus, Dynamics 365 (for non-D365 licensed users), Common Data Service (legacy), and hundreds of other enterprise data sources. Any Power App or Power Automate flow that uses even one premium connector requires every accessing user to have a standalone licence — even if 95% of the app’s functionality uses standard connectors.
This is the trap. An organisation builds a Power App that reads from SharePoint (standard), writes to Teams (standard), and makes one API call to an internal REST service via the HTTP connector (premium). That single premium connector means every user of that app needs a standalone Power Apps licence. If 500 users access the app, the organisation needs either 500 per-user licences (500 × USD 20 = USD 10,000/month) or 500 per-app licences for that specific app (500 × USD 5 = USD 2,500/month). The premium connector cost dwarfs the value of the single API call that triggered it.
A manufacturing company builds a Power App for 800 production floor workers to submit quality inspection reports. The app stores data in SharePoint (standard connector) and sends notifications via Teams (standard). A developer adds a feature that writes critical defects to the company’s SQL Server database for integration with the ERP system — a single premium connector. Suddenly, all 800 users require standalone licensing.
Without the SQL connector: Zero additional cost — fully covered by M365 seeded entitlements.
With the SQL connector (per-user plan): 800 × USD 20/month = USD 16,000/month = USD 192,000/year.
Power Apps standalone licensing offers two models with dramatically different cost profiles. Choosing the wrong model — or failing to negotiate the right model into the EA — is the second-largest source of Power Platform over-spending after premium connector miscalculation.
The per-user plan grants a single user access to unlimited Power Apps using premium connectors, Dataverse, custom connectors, and on-premises gateways. This is the right model for power users who access multiple Power Apps across different business processes — citizen developers, IT staff, department leads, and operational managers who interact with three or more Power Apps regularly. At USD 20/month, the per-user plan breaks even versus per-app at four apps per user (4 × USD 5 = USD 20). Users accessing five or more apps are cheaper on per-user.
The per-app plan grants a user access to one specific Power App (or one portal) using premium connectors and Dataverse. This is the right model for users who access only one or two Power Apps — frontline workers using a single data-entry app, field technicians with one inspection app, or executives viewing one custom dashboard. At USD 5/month per app, per-app is cheaper than per-user for any user accessing three or fewer apps. For large user populations accessing a single app (the quality inspection scenario above), per-app saves 75% versus per-user.
Most organisations need both per-user and per-app licences for different user segments. The EA negotiation should include per-user licences for power users and citizen developers (typically 5–15% of the Power Apps user population) and per-app licences for the larger population of single-app users (typically 85–95% of users). Negotiate volume pricing tiers: Microsoft’s standard pricing applies to small quantities, but EA-level commitments of 500+ per-app licences or 100+ per-user licences typically qualify for 10–25% volume discounts. Additionally, negotiate the right to convert between per-user and per-app during the EA term as usage patterns evolve.
Power Automate licensing has expanded well beyond simple cloud flow automation. The platform now encompasses attended and unattended RPA, process mining, AI Builder integration, and process-based licensing for organisation-wide automations. Each capability has its own licensing requirement, and EA negotiations should address all of them to prevent piecemeal purchasing at standard prices.
Beyond per-user and per-app licences, Power Platform generates capacity-based costs for Dataverse storage and AI Builder consumption that many organisations discover only after deployment. These capacity costs must be addressed in the EA to prevent budget overruns.
Dataverse is the data platform underlying Power Apps, Power Automate, and Dynamics 365. Storage is measured across three categories: database (relational data in Dataverse tables), file (attachments, images, documents), and log (audit logs, activity records). Each Power Apps or Power Automate per-user licence includes a base allocation of Dataverse capacity (typically 250 MB database, 2 GB file per user licence). When organisational usage exceeds the pooled allocation, additional capacity must be purchased at approximately USD 40/GB/month for database and USD 2.50/GB/month for file and log. Organisations with large transactional datasets or extensive audit logging requirements can face thousands in monthly Dataverse overages.
AI Builder provides pre-built and custom AI models (document processing, text classification, object detection, prediction, sentiment analysis) within Power Apps and Power Automate. AI Builder consumption is measured in “service credits” that are consumed each time a model processes data. Certain Power Apps and Power Automate licences include a base allocation of AI Builder credits. Beyond the base allocation, additional credit packs must be purchased (~USD 500/month per 1 million credits). Organisations deploying AI Builder for high-volume document processing or automated classification can exhaust base allocations quickly.
Dataverse storage and AI Builder credits should be negotiated as part of the overall EA rather than purchased as reactive add-ons. Within the EA, negotiate pooled capacity across the organisation (allowing departments with lower usage to offset those with higher usage), volume-based capacity pricing (additional GB at reduced rates for larger commitments), and annual capacity true-ups rather than monthly overages (which carry premium pricing). Organisations that negotiate capacity proactively in the EA typically pay 25–40% less per GB and per credit than those purchasing add-on packs after deployment.
The EA renewal is the single most important moment for Power Platform cost optimisation. Microsoft’s standard pricing applies to individual product purchases; EA-level bundling, volume commitments, and cross-product negotiation create pricing advantages that are not available through any other channel.
Never negotiate Power Platform licensing in isolation. Microsoft’s EA pricing model rewards total commitment value. An organisation negotiating USD 5 million in M365 E5 licences, USD 2 million in Dynamics 365, and USD 500,000 in Power Platform as a single EA package has far more leverage than one purchasing the USD 500,000 Power Platform commitment separately. Use the M365 and D365 spend as leverage: “We will commit to E5 adoption for 3,000 users, but Power Platform per-app pricing must be discounted 25% as part of the package.” Microsoft account teams are authorised to offer deeper Power Platform discounts when they are tied to larger EA commitments.
Analyse actual Power Platform usage across the organisation before the EA negotiation. Identify how many users access multiple premium-connector apps (per-user candidates) versus how many access a single app (per-app candidates). Negotiate the exact mix into the EA: per-user licences for the smaller power-user population, per-app licences for the larger single-app population, and conversion rights to adjust the mix during the EA term. Presenting Microsoft with a data-backed licence mix demonstrates sophistication and reduces the account team’s ability to push higher-cost per-user licences for users who only need per-app.
Instead of purchasing Dataverse storage and AI Builder credits as individual add-ons at list price, negotiate organisational capacity pools within the EA. Request pooled Dataverse capacity that can be shared across all Power Platform workloads (rather than tied to individual licences), annual capacity commitments with reduced per-GB/per-credit rates, and automatic capacity alerts rather than immediate overage charges. The EA should include a mechanism for purchasing additional capacity during the term at the pre-negotiated rate rather than at standard add-on pricing.
Copilot Studio, AI Builder, and other emerging Power Platform capabilities are in a pricing discovery phase where Microsoft is establishing market rates. EA negotiations conducted now have an opportunity to lock in favourable pricing before these products mature and Microsoft standardises higher price points. Negotiate multi-year fixed pricing on Copilot Studio message packs, AI Builder credit pools, and any other emerging Power Platform component. First-mover EA commitments on emerging products typically secure 15–30% better pricing than organisations that wait until the products reach general availability pricing.
Power Platform usage is inherently unpredictable because citizen developers build new apps and automations throughout the EA term. Negotiate flexibility clauses: the right to increase per-app or per-user quantities mid-term at the EA-negotiated price (not list price), the ability to convert between per-user and per-app licences (in both directions) at annual true-up, step-down provisions if Power Platform adoption does not meet projections, and the right to reallocate Dataverse capacity and AI Builder credits across business units without Microsoft approval. These flexibility provisions protect the organisation against both over-commitment and under-commitment scenarios.
Power Platform licensing within EAs fails for predictable reasons. Avoiding these mistakes — most of which occur during EA negotiation or in the months following deployment — prevents the 30–50% over-spending that characterises typical Power Platform estates.
The most expensive and most common mistake. A department requests Power Apps access for 300 users to run one quality management app. IT provisions 300 per-user licences at USD 20/month (USD 72,000/year) when 300 per-app licences at USD 5/month (USD 18,000/year) would provide identical access. The per-user plan is only justified when users access four or more premium-connector apps. For single-app deployments — which represent the majority of Power Apps use cases — per-app saves 75%.
Organisations purchase standalone Power Apps or Power Automate licences for users whose requirements are fully covered by M365 seeded entitlements. If an app uses only standard connectors (SharePoint, Teams, Outlook, Excel), no standalone licence is needed. Before purchasing any standalone licence, verify that the specific app or flow actually uses a premium connector, Dataverse, a custom connector, or an on-premises gateway. Typical organisations find 20–35% of their “required” standalone licences are unnecessary because the apps in question use only standard connectors.
Organisations negotiate per-user and per-app licence quantities without modelling Dataverse storage requirements. Six months after deployment, Dataverse capacity is exhausted, and additional storage must be purchased at list price (often 40–60% more than EA-negotiated rates). Always model expected Dataverse growth during EA negotiation and include capacity pools in the agreement. Underestimating Dataverse storage by even 50 GB can cost an additional USD 2,000/month at list pricing.
Without governance, citizen developers build Power Apps and Power Automate flows that use premium connectors without awareness of licensing implications. Each new premium-connector app creates a licensing obligation for every user. Organisations discover hundreds of premium-connector apps built by business users who assumed M365 covered everything. The resulting licensing true-up at EA renewal is a budget shock. Implement a Power Platform Centre of Excellence (CoE) with connector policies that prevent premium connector usage without licence pre-approval.
Different business units negotiate Power Platform licences independently with separate Microsoft contacts, missing the volume pricing thresholds that a consolidated EA commitment would achieve. Finance buys 50 per-user licences, operations buys 200 per-app licences, and HR buys 30 per-user licences — all at standard pricing. Consolidated through the EA, the same 280 licences would qualify for volume discounts of 10–25%. Centralise all Power Platform requirements into the EA negotiation.
Dynamics 365 licences include Power Platform seeded entitlements — but only within the D365 application context. A D365 Finance user can build Power Apps that extend D365 Finance workflows. That same user building a Power App for an unrelated facilities management process needs a standalone licence for that app. Organisations that assume D365 seeded rights cover all Power Platform usage for D365 users face compliance exposure when Microsoft audits reveal apps and flows operating outside the D365 context.
Effective Power Platform governance prevents the uncontrolled licence sprawl that makes Power Platform one of the fastest-growing — and most unpredictable — cost centres in Microsoft estates. The EA should codify governance mechanisms that align licensing with actual organisational needs.
Microsoft’s Power Platform admin centre allows organisations to create DLP policies that classify connectors into “business,” “non-business,” and “blocked” groups. Use DLP policies to prevent citizen developers from using premium connectors without authorisation. Block premium connectors by default in the default environment; create dedicated environments with premium connectors enabled only for users with confirmed standalone licences. This prevents the accidental premium connector usage that triggers licensing obligations for entire user populations.
Organise Power Platform environments to align with licensing boundaries. Create separate environments for seeded-only usage (standard connectors, M365 data sources) and standalone-licensed usage (premium connectors, Dataverse, custom connectors). This separation enables clear licence assignment: users in the seeded environment need no standalone licence, while users in the premium environment are confirmed standalone licence holders. Environment separation also simplifies compliance auditing and EA true-up reporting.
Deploy the Power Platform CoE Starter Kit (a Microsoft-provided solution) to monitor app usage, flow execution, connector utilisation, and user activity across all environments. Use this data for quarterly licence reviews: identify users with standalone licences who have not accessed premium-connector apps in 90+ days, apps with declining usage that may no longer justify licensing for their user base, and environments with underutilised Dataverse capacity. Typical organisations reclaim 15–25% of standalone Power Platform licences through regular usage monitoring.
Allocate Power Platform licensing costs to the business units that consume them. When department leaders understand that requesting Power Apps per-user licences costs their budget USD 20/user/month (versus USD 5 for per-app), they make more informed decisions about licence tier selection. Chargeback also motivates business units to review and return unused licences proactively. Combine chargeback with a request workflow: all Power Platform licence requests must specify the app, the connectors used, the user count, and the business justification before IT provisions the licence.
The EA renewal is a three-year pricing lock. Every Power Platform decision made during negotiation determines costs for 36 months. The following checklist ensures the organisation enters the renewal with the data, analysis, and strategy needed to optimise Power Platform within the EA.
Power Platform licensing sits at the intersection of M365 plan strategy, D365 entitlements, capacity planning, citizen development governance, and EA negotiation. Independent advisory provides the cross-domain expertise needed to optimise all dimensions simultaneously.
Redress Compliance conducts comprehensive Power Platform licensing assessments: connector classification (standard vs premium) for every app and flow, user segmentation (seeded vs per-app vs per-user), Dataverse and AI Builder capacity modelling, and D365 seeded entitlement verification. Our assessments typically identify 20–40% savings by reclassifying users from per-user to per-app, eliminating standalone licences where seeded entitlements suffice, and consolidating capacity purchases. We provide the data-backed licence mix that serves as the foundation for EA negotiation.
We support the EA renewal negotiation with Power Platform-specific intelligence: market pricing benchmarks, volume discount thresholds, bundling strategies that link Power Platform to M365 and D365 commitments, and flexibility clause language that protects the organisation against citizen development unpredictability. Our EA negotiation support consistently achieves 15–30% below-list-price outcomes for Power Platform while securing the conversion rights and capacity provisions that prevent mid-term budget overruns.
Redress Compliance has no Microsoft partnership, no CSP resale revenue, and no incentive to recommend specific Power Platform tiers or adoption levels. Our recommendations on licence mix, capacity sizing, and EA negotiation strategy are based exclusively on the organisation’s requirements and financial objectives. This independence is particularly important for Power Platform, where Microsoft account teams are incentivised to drive per-user adoption and Copilot Studio commitments regardless of whether the organisation’s usage patterns justify those investments.
“Power Platform licensing within the Enterprise Agreement is where the most significant Microsoft cost optimisation opportunities exist for most organisations today. The combination of seeded entitlements that create false confidence, premium connectors that trigger expensive standalone requirements, per-user plans deployed where per-app would suffice, and capacity costs that surface months after deployment creates a licensing landscape where 30–50% over-spending is the norm rather than the exception. The organisations that control Power Platform costs are those that inventory every app and connector, segment users rigorously by licence need, negotiate the per-user/per-app mix and capacity pools into the EA, and implement governance that prevents uncontrolled premium connector proliferation.”
Redress Compliance delivers independent Power Platform licensing advisory — connector classification, user segmentation, per-user vs per-app optimisation, Dataverse capacity planning, EA negotiation support, and governance framework design. We identify 20–40% savings in Power Platform costs through strategic EA bundling. Complete vendor independence. No Microsoft partnerships, no resale commissions.