Almanac
Microsoft/power-appsPower Platform

Consultant KB for Microsoft Power Apps: canvas apps, model-driven apps, Power Fx, data and connections, controls and UI, code and extensibility, mobile and offline, ALM and solutions, governance and security, licensing and performance, plus cross-cutting decision guides. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power Apps release plans, docs repo and product blog, plus the author's own consultant notes.

power-apps/10-licensing-and-performance/feature-premium-connector-licensing.md
feature-premium-connector-licensing.mdv1 · history
CurrentApplies to BothUpdated last monthSource Microsoft Learn ↗

What it does

Every app carries a licence designation — Standard, Extended or Premium — calculated from what it connects to. Premium is triggered by any premium connector, any custom connector, or an on-premises data gateway, and it changes who is allowed to run the app.

Key facts

  • Standard: only standard connectors. Runnable by users with Power Apps for Microsoft 365, a per app plan, or a per user plan.
  • Extended: apps that were using connectors promoted to premium on 1 October 2019 and were granted a grandfathered window. Same user entitlement as Standard.
  • Premium: at least one premium connector, a custom connector, or an on-premises gateway. Requires a per app plan or a per user plan.
  • Dataverse, SQL Server, the Azure connectors and the Dynamics 365 connector are all premium. Dataverse is also the one premium connector that classic data policies can't block.
  • Apps built in Microsoft Teams environments that connect to Dataverse for Teams, or that use custom connectors, are designated Premium. Users with Microsoft 365 subscriptions carrying Dataverse for Teams rights can run them inside Teams; running the same app outside Teams needs a per app or per user plan.
  • The designation is visible in two places in the maker portal — app Settings, and app Details.
  • The designation is a static calculation on the app's own connections. It's not a licence check at runtime.

When to use / skip

There's nothing to turn on, so the real question is how early you find out. Check the designation before you commit to a data source, not after the app is built. The pattern that costs projects money: prototype against SharePoint, demo it, get told it's brilliant, then discover the real data lives in SQL and every one of the four hundred intended users now needs a premium licence nobody budgeted for. Where a client genuinely can't fund premium for a wide population, the design conversation is whether the data can be surfaced through a standard connector at all — often it can't, and that's a project decision rather than a technical one.

Configuration decisions

  • Which data sources are in scope, and whether any of them push the app to Premium. This is a licensing decision disguised as an architecture decision.
  • Whether a gateway is used, since the gateway alone triggers Premium regardless of what's behind it.
  • Whether custom connectors are acceptable, given they force Premium and are also currently outside advanced connector policies.
  • For Teams-based apps, whether users will only ever run them inside Teams — because outside Teams the entitlement changes.
  • Whether the population is licensed per user or covered by per app capacity allocated to the environment.

Gotchas

  • The big one, and Microsoft documents it as a known issue: a premium connector used in a flow that the app calls doesn't affect the app's designation. An app using only standard connectors that calls a flow using HTTP shows as Standard while genuinely requiring Premium use rights from its users. The designation is not a compliance check.
  • Design-time doesn't stop you. There's no gate that prevents a maker building a Premium app and sharing it with unlicensed users — they find out at run time, or at audit.
  • The Extended designation is a legacy grandfathering artefact from October 2019. If you see it, understand it as a historical concession rather than a category to design toward.
  • Premium licence checks and DLP classification are different things using similar words. A connector can be premium and unblockable (Dataverse), or standard and blocked. Don't conflate the two lists.
  • Adding one lookup to a SQL table late in build changes the licensing for every user of the app.

Consultant notes

  • Check the designation at the end of every sprint, not at the end of the project. It's two clicks and it's the cheapest licensing control you have.
  • Tell the client explicitly that the designation doesn't account for flows. If their compliance position rests on "the portal says Standard", it's wrong.
  • Use Power Platform inventory's connector column (preview) to see premium connector adoption across the estate — it's the fastest way to answer "how many of our apps actually need premium licences".
  • When a client pushes back on premium cost, the useful reframe is per app capacity allocated to a single environment. It's a smaller commitment and it makes the pilot fundable.

Worth revisiting if Microsoft ever makes the designation account for connected flows, or reclassifies another batch of connectors.

Was this accurate?
Related
Connectors in Power Apps04-data-and-connectionsPower Apps licensing10-licensing-and-performancePower Apps licensing decision guide11-decision-guidesAPI request limits for apps10-licensing-and-performanceOn-premises data gateway04-data-and-connectionsCanvas apps in Teams and Dataverse for Teams01-canvas-apps