Almanac

Consultant KB for Microsoft Power Automate end to end: cloud flows, desktop flows and RPA, connectors and integration, AI and agent flows, process and task mining, approvals and human-in-the-loop, ALM and solutions, governance and security, licensing and capacity, monitoring and troubleshooting, 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 Automate release plans, docs repo and product blog, plus the author's own consultant notes.

feature-premium-connector-licensing.mdv1 · history
CurrentApplies to Cloud flowsUpdated last monthSource Microsoft Learn

What it does

Adding a premium or custom connector to a cloud flow raises the licence bar for that flow. Whether that's satisfied depends on which licence context the flow runs in — the owner's, the invoking user's, or a Process licence assigned to the flow itself.

Key facts

  • Standard connectors are covered by Microsoft 365 seeded rights. Premium and custom connectors are not.
  • Automated and scheduled flows run in the owner's context. If such a flow uses a premium connector, only the owner needs the premium entitlement.
  • Instant flows — button, Power Apps, hybrid triggers — run in the invoking user's context. Every person who runs a premium instant flow needs their own premium entitlement.
  • A Process licence assigned to a flow overrides all of it. The flow gets premium and custom connector rights and uses the Process limits regardless of who owns or runs it, and no user needs a licence for that flow.
  • Power Apps and Dynamics 365 seeded licences grant premium connectors only where the flow is in-context and associated with that app. An automated flow needs the owner licensed; an instant flow needs every running user licensed.
  • Connections are independent of licence checks. You can have several users' connections in one flow and the licence context is still the owner, the run-only user, or the Process licence.
  • A child flow inherits the parent's context unless it has its own Process licence. During the current transition period the child uses its own owner's licence instead, and that reverts when the transition ends.
  • If a service principal owns the flow, it draws on the tenant's non-licensed user pool rather than a user entitlement.
  • In Power Automate, adding an AI Builder action doesn't make a flow premium. In Power Apps, adding an AI Builder action — including via an embedded flow — does make the app premium.

When to use / skip

Reach for premium connectors when the integration genuinely needs them, and check the licence position in the same breath rather than afterwards. Where a premium flow will be invoked by a wide or unknown audience — including guests whose home tenant licensing you can't see — put a Process licence on the flow instead of trying to licence every user. Where only a service account owns and runs it on a schedule, one Premium licence on that account is usually the cheap answer.

Configuration decisions

  • Whether the flow is triggered automatically or manually, since that alone decides whether one person or every person needs the licence.
  • Whether to licence the users or licence the flow, which is largely an arithmetic question once you know the audience size.
  • Whether a genuinely premium requirement can be avoided — a standard connector or a built-in action sometimes does the job.
  • Who owns the flow, because ownership is the licence context for anything automated.
  • Whether the environment moves to pay-as-you-go, where premium capabilities are available without upfront licences.

Gotchas

  • A licence check happens at design time and at run time. A flow can save and then fail later when the owner's licence position changes, which is why the 14-day turn-off notice exists.
  • Instant flows are the expensive shape. Converting a premium instant flow to an automated one owned by a service account can change the licence bill dramatically for no functional difference.
  • Guest users need a licence from either tenant, and you usually can't see their home tenant position. This is exactly the case Microsoft cites for putting a Process licence on the flow.
  • HTTP actions are premium. A flow that quietly gained one during development has changed its licence requirement and nobody logged it.
  • Custom connectors carry the same premium requirement as premium connectors, which catches teams who built a custom connector to avoid one.

Consultant notes

  • Ask "who triggers this, and how many of them are there" in every design session. It's the question that determines the licence, and it's cheap to ask early.
  • Document the licence basis for each flow alongside the design. When someone changes a trigger from scheduled to button eighteen months later, that note is the only thing standing between the client and an unbudgeted cost.
  • Be blunt that connections and licences are separate. Clients routinely assume that because a service account holds the connection, the service account's licence covers everyone.
  • Don't name or price SKUs from memory in front of a client. Refer them to the Power Platform Licensing Guide and their account team.

Worth revisiting when the Power Automate transition period ends, since child flow licence inheritance changes at that point.

Was this accurate?