The Seeded Capability Model — and Why It Creates Problems
Microsoft 365 E1, E3, and E5 licences include what Microsoft calls "seeded" Power Platform capabilities — a subset of Power Apps and Power Automate functionality that is available to M365 users without a separate Power Platform licence. These seeded capabilities are deliberately limited in scope: they cover scenarios that are native to M365 applications (SharePoint, Teams, Outlook) and exclude the full Power Platform feature set that organisations need for substantive business automation and application development.
The commercial problem is that the boundary between seeded capabilities and licensed capabilities is not clearly communicated in Microsoft's standard product documentation. Organisations routinely build Power Apps and Power Automate flows using what they believe are seeded M365 entitlements, only to discover at true-up that their workloads have crossed into functionality that requires standalone Power Platform licences. The compliance gap — between what M365 includes and what the organisation has actually deployed — is the most common Power Platform audit finding we encounter. Understanding exactly where the line sits prevents both this compliance risk and the opposite problem: purchasing standalone Power Platform licences for workloads that are already covered by M365 entitlements.
Power Apps: What M365 Actually Gives You
M365 E1, E3, and E5 licences include the ability to run Power Apps canvas applications that connect only to M365 data sources and Microsoft Dataverse for Teams. The full list of approved connectors for seeded Power Apps usage is explicitly defined in Microsoft's service description: SharePoint, OneDrive for Business, Teams, Exchange Online, and a small number of other M365-native connectors. Applications that connect to these data sources, and only these data sources, can run under the M365 seeded entitlement.
The boundary is connector-based. The moment a Power App connects to a non-M365 data source — SQL Server, Salesforce, ServiceNow, a custom API, or even a standard connector like Approvals in certain configurations — it moves into territory that requires a Power Apps Per User, Per App, or Pay-As-You-Go licence. This is not a grey area in Microsoft's licensing terms; it is explicitly defined in the service description. The practical challenge is that many organisations build apps that start with M365 connectors and then add non-M365 connectors as requirements evolve, without reassessing the licence position at each stage of development.
Dataverse for Teams vs full Dataverse
Seeded Power Apps usage in M365 includes Microsoft Dataverse for Teams — a version of Dataverse hosted within the Teams environment with capacity limits of 2 GB per team environment and a 1 million row limit. Dataverse for Teams supports basic app and flow development for Teams-native scenarios. Full Dataverse — the enterprise data platform that supports complex relational data models, relationships across environments, Dynamics 365 integration, and Dataverse search — requires a Power Apps or Dynamics 365 licence that provides Dataverse capacity entitlements. Organisations that outgrow Dataverse for Teams (hitting capacity limits or requiring features only available in full Dataverse) face an upgrade path that involves either a Power Apps Per User licence or Dataverse capacity add-ons. For the full Dataverse licensing breakdown, see our Dataverse licensing guide.
Power Automate: The Standard Connector Boundary
M365 licences include Power Automate with Standard connectors — a substantial list that covers M365 services, SharePoint, OneDrive, Teams, Outlook, and hundreds of third-party SaaS applications including Salesforce, ServiceNow, and Dropbox when accessed through Standard connectors. Standard connector flows that run on triggers and actions from this approved list are covered by the M365 seeded entitlement.
The boundary for Power Automate falls at Premium connectors and Premium features. Premium connectors — those that require a Power Automate Premium licence — include connectors to on-premises data (requiring the on-premises data gateway in Premium mode), HTTP connectors that call custom APIs, certain Dynamics 365 connectors, and a list of designated Premium connectors that changes periodically as Microsoft reclassifies connectors. Business process flows (BPF), which provide structured approval workflows in Dataverse, require a Power Automate Premium licence. Robotic process automation (RPA) capabilities through Power Automate Desktop require either a Power Automate Premium licence or a separate RPA add-on. An M365 licence with seeded Power Automate covers Standard connector flows only; Premium connector usage is a compliance gap that generates true-up liability.
The attended vs unattended RPA distinction
Power Automate Desktop is available free to Windows 10/11 users for attended RPA — desktop automation that runs with a human present at the workstation, executing actions in the foreground. Unattended RPA — automation that runs without a user logged in, typically on a virtual machine or server environment for high-volume processing — requires a Power Automate Process licence ($150/bot/month) that is entirely outside the M365 seeded model. This distinction catches organisations that pilot attended automation in their M365 environment and then move to unattended automation for scale without recognising the separate licence requirement. For the complete Power Automate licensing breakdown, see our Power Automate licensing guide.
Power BI: E5 Includes Pro — E1 and E3 Do Not
Microsoft 365 E5 includes Power BI Pro as a bundled benefit. This is one of the most commonly missed E5 entitlements: organisations with significant E5 populations continue paying for standalone Power BI Pro licences for users who are already licenced through E5. The reconciliation — removing duplicate Pro assignments from E5 users — is typically a quick win that generates $8–10/user/month in unnecessary licence spend. For a 500-user E5 deployment where 200 users also have standalone Pro licences, the waste is approximately $20,000/year.
M365 E1 and E3 do not include Power BI Pro. Users on E1 or E3 who need to share Power BI content, access shared workspaces, or collaborate in the standard Power BI collaborative model require a standalone Pro licence ($10/user/month at list; approximately $8.50 at EA rates). The Power BI Free tier — which gives access to personal workspace and report development but no sharing — is available to all M365 users without any additional licence. For organisations evaluating whether their E3 users need Pro, the question is whether they are sharing reports and accessing shared workspaces (Pro required) or developing reports solely for personal use (Free tier is adequate). For the complete Power BI licensing breakdown, see our Power BI licensing guide.
| Power Platform Product | M365 E1 | M365 E3 | M365 E5 | Standalone Required When… |
|---|---|---|---|---|
| Power Apps | M365 connectors only | M365 connectors only | M365 connectors only | Non-M365 connectors or full Dataverse |
| Power Automate | Standard connectors only | Standard connectors only | Standard connectors only | Premium connectors, BPF, or unattended RPA |
| Power BI | Free only (no sharing) | Free only (no sharing) | Pro included | E1/E3 users needing sharing or workspace access |
| Power Pages | — | — | — | Always requires standalone licence (per-user or per-website) |
| Dataverse | Dataverse for Teams only | Dataverse for Teams only | Dataverse for Teams only | Full Dataverse requires Power Apps or D365 licence |
| AI Builder | — | — | — | Always requires AI Builder credits (standalone or add-on) |
| Copilot Studio | — | — | — | Always requires Copilot Studio (message capacity model) |
Compliance Implications: The True-Up Risk
Power Platform compliance gaps in M365-licenced environments cluster around three patterns. The first is connector scope creep in Power Apps: an app starts with SharePoint and Teams connectors (seeded, compliant) and later adds SQL Server or a Premium connector to extend functionality. The licence position changes at the point the Premium connector is added, but the licence assignment often isn't updated, creating a backdated compliance exposure that may only surface at true-up. Running a connector audit against your Power Apps environment — available through the Power Platform admin centre's analytics — identifies which apps have crossed into Premium territory.
The second pattern is Power Automate Premium connector adoption without licence assignment. As automations evolve, developers add Premium connectors (on-premises gateway, HTTP, Dynamics 365) to existing flows that started as Standard connector flows. Without governance controls that flag Premium connector usage and trigger licence provisioning, these flows run non-compliantly. The admin centre's flow analytics shows connector usage by flow and can be used as a compliance audit tool.
The third pattern is Dataverse capacity overrun. Organisations using Dataverse for Teams who exceed the 2 GB or 1 million row limits find their apps degrading; the resolution requires upgrading to full Dataverse, which requires a Power Apps Per User licence or capacity add-on. The capacity upgrade decision often happens reactively — under pressure from app performance issues — rather than proactively as part of licence planning. Building capacity monitoring into your Power Platform governance framework (see our Power Platform governance guide) prevents reactive licence scrambles at renewal time.
If your Power Apps or Power Automate usage has grown organically since your last EA renewal, there is a meaningful probability that your current deployments include Premium connectors or Premium features that exceed your M365 seeded entitlements. The liability is calculated on peak deployment during the true-up period — not just current state. A connector audit before your annual true-up date is the minimum governance step. See our Microsoft true-up compliance guide for the full liability calculation framework.
The EA Negotiation Angle: Using M365 Scope as Leverage
Understanding what M365 includes for Power Platform has a direct negotiation application: it defines the minimum value you are already receiving from your M365 commitment, which affects how you should value standalone Power Platform licences. When Microsoft's account team presents a Power Platform upsell as additional capability, the correct response is to first establish exactly which workloads you have that exceed the M365 seeded entitlements, and then size the licence requirement precisely — not based on Microsoft's recommendation, but based on your own audit of connector usage and feature requirements.
Organisations that have accurately mapped their Power Platform compliance position before entering renewal negotiations are in a structurally stronger commercial position: they negotiate from data rather than estimate, they can challenge inflated licence counts with their own usage evidence, and they are not vulnerable to the uncertainty discount that leads some buyers to over-purchase "to be safe." For the full negotiation framework for Power Platform licences within an EA context, see our Power Platform licensing complete guide and our EA negotiation advisory service. For the broader M365 optimisation framework, see our guide on reducing M365 costs at renewal.