Power Apps Premium Connectors List: What Requires Extra Licensing?

Overview

If you want the short version, here it is: in Power Apps, the licensing question is usually less about how many screens your app has and more about what services it touches. As soon as an app uses a premium connector, or relies on certain premium platform capabilities such as Dataverse in common licensing scenarios, you should assume you need to validate premium licensing requirements before rollout.

The safest evergreen interpretation is this:

• Standard connectors are generally included in more common Microsoft 365-oriented scenarios.
• Premium connectors typically require additional Power Apps licensing beyond basic included rights.
• Dataverse is commonly treated as a premium boundary in planning, especially when it becomes the core data layer for an app.
• Custom connectors should be treated as premium unless current Microsoft documentation clearly says otherwise.

That framing matters because teams often search for a static “premium connectors list,” but the real operational problem is broader: connector classifications, entitlement rules, and packaging can change over time. So the most useful asset is not a one-off spreadsheet. It is a repeatable review process.

For app builders, IT admins, and solution architects, the practical question is not just “Is connector X premium?” It is:

• What data sources does this app use today?
• What data sources will it likely use next quarter?
• Will every user of the app need the same license?
• Can we redesign the integration boundary before we commit to a licensing model?

In other words, connector licensing is architecture. If you catch it early, it is manageable. If you discover it after user acceptance testing, it becomes a budget and governance issue.

As context, Power Apps is widely positioned as a low-code app development platform for building business applications quickly, with drag-and-drop tooling, prebuilt components, and integration options that work across both business users and professional developers. That flexibility is one reason licensing questions come up so often: the platform makes it easy to expand from simple internal forms into more complex, multi-system applications. If you are comparing where Power Apps fits against other app development platforms, see Power Apps vs Bubble vs FlutterFlow: Which App Builder Fits Your Use Case?.

For maintenance purposes, it helps to group premium-triggering scenarios into a few buckets rather than memorizing individual connector names:

1. External business systems: CRM, ERP, finance, support, and line-of-business SaaS tools often land on the premium side.
2. Database and enterprise data services: SQL-style sources, enterprise APIs, and Dataverse-backed solutions frequently move an app beyond basic included entitlements.
3. Custom integration layers: if you build your own API wrapper or custom connector, plan for premium review.
4. Internal tools with cross-system orchestration: apps that aggregate multiple systems are especially likely to require premium licensing.

This is why licensing should be reviewed during discovery, not after the app is approved. On internal tools projects, connector choice can have a larger cost impact than the UI build itself. If your team is evaluating Power Apps alongside other internal tools platforms, Power Apps vs Retool vs Appsmith: Best Internal Tools Platform for 2026 is a useful companion read.

Maintenance cycle

The most useful way to maintain a Power Apps premium connectors list is to stop treating it as a publish-once artifact. Instead, create a lightweight review cycle tied to how your organization actually ships apps. This section gives you a repeatable method.

What the reader gets from this section: a practical workflow for keeping connector licensing guidance current without rebuilding the document every time Microsoft updates product packaging.

1. Keep a three-column connector register

For every app in production or active development, maintain a simple register with:

• Connector or data source name
• Current internal classification: standard, premium, needs verification
• Business impact: who uses it, which app depends on it, and whether it affects all users or only makers/admins

This is more useful than a raw list of connector names because it turns licensing into an operational inventory. If a connector changes classification, you can immediately see which apps and user groups are affected.

2. Review on a fixed schedule

A good baseline is a quarterly review, with a lighter monthly check for organizations that build frequently. The point is not to read every product page from scratch. It is to confirm whether your current assumptions still hold.

During the scheduled review:

• Check Microsoft’s current connector classification pages and licensing documentation.
• Review new apps created since the last cycle.
• Scan existing apps for newly added connectors, custom connectors, or Dataverse usage.
• Validate whether trial builds have become production dependencies.

If your environment changes quickly, align this review to your existing governance cadence. Many teams already have monthly platform reviews for security, DLP, and environment management. Connector licensing belongs in the same rhythm.

3. Separate design-time from run-time licensing questions

One common source of confusion is assuming that only the app maker needs premium rights because the maker set up the connection. In practice, the important question is usually whether the published app, flow, or data path depends on premium capabilities for end users.

When reviewing an app, ask:

• Does the user directly interact with a premium connector?
• Is a Power Automate flow in the middle, and does that flow use premium components?
• Does the app depend on Dataverse tables, forms, or business logic?
• Are there service accounts or shared connections that hide the true dependency?

This avoids the classic mistake of declaring an app “safe” because it worked in a developer sandbox.

4. Flag architecture choices that lock in premium licensing

Some apps can be redesigned early to reduce licensing complexity. Others are inherently premium because of the systems involved. Your maintenance process should record which is which.

For each app, add one note:

• Premium by necessity: for example, the business process depends on enterprise SaaS or Dataverse-centric functionality.
• Premium by design choice: the team chose a premium connector even though an alternative data path may exist.

That note is valuable during renewal planning and platform selection. It also prevents teams from assuming a cost was unavoidable when it was really a design tradeoff.

5. Pair the connector list with a pricing review

A connectors list without a pricing checkpoint is incomplete. If your organization is evaluating whether Power Apps remains the best app development platform for a given use case, licensing details can materially change the outcome. Keep a link to your internal pricing assumptions or to a current pricing guide beside the connector register. For a broader planning view, see Microsoft Power Apps Pricing Guide: Plans, Licensing Limits, and Hidden Costs.

Signals that require updates

This section helps you spot when your premium connectors reference needs immediate attention, not just the next scheduled review.

What the reader gets from this section: a checklist of change signals that usually mean your existing connector licensing assumptions may be out of date.

New connector added to an existing app

This is the most obvious trigger. A business app that originally used only Microsoft 365 services may cross into premium territory the moment it adds a nonstandard SaaS system, a database connector, or a custom API. Make connector review part of change management, not just initial app approval.

Dataverse becomes the system of record

Teams often prototype with Excel, SharePoint, or a simple list-based approach, then move to Dataverse as the app matures. That is often the right technical move, but it is also a licensing trigger worth documenting clearly. If Dataverse is introduced for relational data, business rules, security modeling, or scalable app logic, revisit user licensing assumptions immediately.

Custom connector introduced for an internal API

Custom connectors are a frequent blind spot because they feel “internal.” But from a licensing standpoint, custom integration is exactly the kind of capability that should trigger a premium review. The fact that the API is your own does not automatically make the licensing implications simpler.

Power Automate flows are added behind the scenes

An app may appear to use only standard sources, but the actual business process runs through flows that connect to premium services. This is where ownership boundaries matter. The app team may not realize that the automation team changed the integration path. Review apps and associated flows together.

Microsoft updates product packaging or terminology

Licensing pages and plan names can change, and classification language can become more specific over time. Even if the underlying business impact is similar, older internal guidance may become misleading. The safest maintenance habit is to update your wording whenever Microsoft changes how rights are described.

Search intent shifts in your own organization

This article is designed as a maintenance-style resource for a reason: the topic evolves as reader questions evolve. A year ago, the main question may have been “Which connectors are premium?” Now it may be “Does this internal tools architecture force premium for all users?” If the repeated questions from developers, procurement, or platform admins change, your reference doc should change too.

Common issues

Most Power Apps licensing mistakes are not caused by obscure edge cases. They come from a handful of recurring planning errors. This section gives you a practical way to prevent them.

What the reader gets from this section: the most common failure patterns when managing premium connectors, plus a safer way to handle each one.

Issue 1: Treating a community-made connector list as authoritative

Third-party lists can be useful starting points, but they age quickly. For anything tied to licensing, your internal source of truth should always point back to current Microsoft documentation. Use external lists for discovery, not policy.

Safer approach: keep your own internal list with a verification date and a link to the official source checked during that review cycle.

Issue 2: Assuming “included with Microsoft 365” covers the whole app

This is one of the most expensive mistakes in Power Apps planning. An app may begin in a Microsoft 365-friendly pattern and still require premium licensing later because of one added connector or a move to Dataverse-backed logic.

Safer approach: classify the app by its highest licensing dependency, not by how it started.

Issue 3: Looking only at the canvas app and ignoring connected assets

Power Apps solutions rarely exist alone. They often include Power Automate, Dataverse tables, security roles, environment policies, and APIs. Connector licensing should be assessed at the solution level.

Safer approach: document the full dependency chain: app, flows, connectors, data store, and authentication pattern.

Issue 4: Confusing technical feasibility with licensing feasibility

Because Power Apps is a mature low-code platform, many integrations are technically straightforward. That does not mean they are cost-neutral. Teams sometimes choose a connector because it accelerates delivery, then discover that scaling to hundreds or thousands of users changes the economics.

Safer approach: include licensing impact in architecture reviews alongside security, performance, and maintainability.

Issue 5: Forgetting governance when citizen development expands

In organizations with active maker communities, premium usage can spread quietly. A business unit may create a useful internal app, add a premium data source, and only later involve central IT. By then, reversing the design may be harder than licensing it.

Safer approach: define an approval checkpoint for any app that uses Dataverse, custom connectors, enterprise databases, or external line-of-business systems.

If your organization is choosing among low-code options for governed enterprise delivery, Best Low-Code Platforms for Enterprise Apps: Features, Governance, and Pricing Compared offers a broader selection framework.

When to revisit

This final section turns the article into a working maintenance checklist you can return to. If you only keep one part of this guide, keep this one.

What the reader gets from this section: a practical action plan for deciding when your Power Apps premium connectors list should be reviewed, refreshed, or rewritten.

Revisit on a scheduled review cycle

At minimum, review your internal premium connectors reference every quarter. If your environment has frequent app launches, monthly is better. During the review:

1. Export or list all production apps and major in-flight apps.
2. Record every connector and data source used by each app.
3. Flag Dataverse usage explicitly.
4. Check for custom connectors and premium flows.
5. Verify current classification against official Microsoft documentation.
6. Update app owners and affected user counts.
7. Note any apps that may need redesign, new licenses, or procurement review.

Revisit when a project changes scope

Do not wait for the quarterly review if any of the following happens:

• A SharePoint-based app moves to Dataverse.
• An app adds SQL, Salesforce, ServiceNow, SAP, or another external business system.
• A custom connector is introduced.
• A flow is added that calls premium services.
• The app shifts from pilot users to broad production rollout.

Those are not minor implementation details. They are licensing events.

Revisit when search intent or stakeholder questions change

If you maintain documentation for a platform team, pay attention to the questions people actually ask. When admins start asking about governance rather than connector names, your guide should expand to include approval paths. When finance starts asking about user impact, your guide should map premium dependencies to user groups. A good maintenance article evolves with the operational questions around it.

Use this simple rule of thumb

If an app touches systems beyond basic Microsoft 365-style collaboration data, assume a premium review is required until current documentation proves otherwise. That rule is conservative, but it reduces costly surprises.

Build your own reusable checklist

For teams that want a durable process, create a one-page checklist with these prompts:

• What connectors does the app use today?
• What connectors are planned next?
• Does it use Dataverse?
• Does it use custom connectors?
• Does any related flow use premium capabilities?
• Who are the end users?
• What licensing assumption has been approved?
• When was this last verified?

That turns a confusing licensing topic into a repeatable review pattern. And that is the real value of a premium connectors list: not memorizing every connector forever, but creating a reliable habit of checking the right things before costs and rollout plans drift apart.

Used this way, your connector reference becomes a living part of Power Apps delivery governance. It stays relevant whether you are building a small internal form, a Dataverse-centered business app, or a larger low-code solution that needs to scale across departments.