Understanding Power Apps Licensing: Choosing the Right Plan for Your App and Users

You've built something useful. A canvas app that lets your warehouse team log inventory counts directly from their phones, or a form that replaces a twelve-tab Excel file your finance team somehow kept alive for six years. The app works. People want to use it. And then someone from IT or procurement asks the question that stops every new Power Apps developer cold: "What license do these users need?"

If you've ever stared at Microsoft's licensing page and felt like you were reading a contract written in a language that uses English words but doesn't quite make English sentences, you're not alone. Power Apps licensing is genuinely confusing — not because Microsoft is trying to hide anything, but because the platform sits at the intersection of enterprise software, cloud services, and a pricing model that has evolved significantly over the past few years. Getting this wrong costs real money. Getting it right means you can deploy your app with confidence, knowing you're not going to trigger a compliance conversation six months later.

By the end of this lesson, you'll understand exactly how Power Apps licensing works, what each plan covers, and how to reason through licensing decisions for your specific app and user base. You'll also understand the key technical concepts — like premium connectors and Dataverse — that drive most licensing decisions.

What you'll learn:

• The fundamental difference between Microsoft 365 (seeded) Power Apps access and standalone Power Apps licenses
• What makes a connector "premium" and why that matters for licensing
• How to evaluate the Power Apps per-user plan versus the per-app plan
• How Dataverse changes the licensing equation
• A practical decision framework you can apply to any app you build

---

Prerequisites

You don't need any prior Power Apps experience for this lesson — we're covering the business and architectural concepts, not hands-on app building. However, it helps to have a general sense of what Power Apps is: a low-code platform from Microsoft that lets you build custom business applications that can connect to data sources like SharePoint, Excel, SQL Server, Salesforce, and hundreds of others. If you've opened Power Apps at least once and poked around, you're ready.

---

The Foundation: Why Does Power Apps Have a Complicated Licensing Model?

Before we get into plans and prices, let's build some intuition for why this licensing model exists. This will make everything else click faster.

Power Apps is not a single product. It's more like a surface — an interface — that sits on top of Microsoft's broader cloud platform. When your app connects to SharePoint, it's using SharePoint infrastructure. When it reads from SQL Server, it's hitting your SQL Server. When it writes to Salesforce, it's making API calls to Salesforce. Microsoft has to pay for some of this infrastructure, and they have agreements with third-party data providers that have their own commercial terms.

The licensing model essentially reflects two questions:

1. What data sources is your app connecting to? Some connections use infrastructure that's already covered by your Microsoft 365 subscription. Others use premium infrastructure or third-party APIs that require additional licensing.
2. How many apps does each user need to run? A user who only needs to run one specific business app has different needs than a power user or a developer who's accessing a portfolio of apps.

Once you understand that the licensing model is answering those two questions, everything else makes much more sense.

---

The Baseline: What Comes with Microsoft 365

Many organizations are surprised to discover that their employees already have some Power Apps access through their existing Microsoft 365 subscriptions. This is often called "seeded" Power Apps access, because it's bundled in rather than purchased separately.

If your organization uses Microsoft 365 Business Basic, Business Standard, Business Premium, or most E-tier enterprise plans (E1, E3, E5), your users already have the ability to run and build certain Power Apps — specifically apps that connect only to standard connectors.

Think of connectors as the plumbing between your app and its data sources. A connector is a pre-built integration that handles the authentication and API calls to a specific service. Standard connectors include things you likely already use:

• SharePoint — reading from and writing to SharePoint lists
• Excel Online — connecting to Excel files stored in OneDrive or SharePoint
• OneDrive for Business — accessing files in cloud storage
• Teams — posting messages or reading channel data
• Outlook — sending emails from your app
• Forms — pulling data from Microsoft Forms responses
• Planner — reading and creating Planner tasks

If you build an app that uses only these standard connectors, users with an eligible Microsoft 365 license can run it without any additional Power Apps license. This is genuinely useful, and a lot of practical internal tools live entirely in this space.

Tip: The full, current list of standard versus premium connectors is published on Microsoft's documentation site and gets updated periodically. Before you finalize your app's data connections, it's worth checking whether each connector you're using is standard or premium — this single decision often determines whether your organization needs additional licensing spend.

---

The Dividing Line: Standard vs. Premium Connectors

Here's where most licensing surprises come from. The moment your app uses even one premium connector, every user of that app needs either a Power Apps per-user plan or a Power Apps per-app plan.

Premium connectors are integrations with services that either use Microsoft's premium gateway infrastructure or connect to third-party platforms. Examples include:

• SQL Server (when connecting via a direct connection, rather than a gateway to on-premises SQL — though gateway also requires premium)
• Salesforce — a third-party CRM platform
• SAP — enterprise ERP software
• Dataverse — Microsoft's own enterprise-grade database service built for the Power Platform
• DocuSign — electronic signature service
• Adobe Sign
• ServiceNow
• Any custom connector you build yourself using a REST API

Notice that Dataverse is on that list. This surprises a lot of new Power Apps developers because Dataverse is a Microsoft product, built specifically for Power Apps. Why would using it require a premium license? The answer is that Dataverse is a full-featured cloud database service with storage, security roles, relationships, and API access — it's not lightweight cloud storage like SharePoint lists. The infrastructure costs are meaningfully different, and Microsoft licenses it separately.

Warning: A common mistake is to prototype an app using SQL Server as the backend — which works great and is very powerful — without realizing that SQL Server is a premium connector. When it comes time to deploy to 50 users, the licensing cost suddenly enters the conversation. Know your connector types early in the design process.

Let's make this concrete with a scenario.

Scenario A: Your HR team wants a Power App where managers can submit vacation approval requests. The data is stored in a SharePoint list, notifications go through Outlook, and the workflow is simple. All standard connectors. Users with Microsoft 365 licenses can run this app at no additional cost.

Scenario B: Your operations team wants a Power App where field technicians can look up work orders from ServiceNow, update their status, and log parts used against inventory in your SQL Server database. Both ServiceNow and SQL Server are premium connectors. Every user of this app needs a Power Apps license.

That distinction — Scenario A versus Scenario B — is the most important licensing decision you'll make.

---

The Two Main Standalone Plans: Per-User and Per-App

Once you've determined that your app needs premium connectors, you're choosing between two main licensing approaches. (We'll cover Dataverse-specific nuances in the next section.)

Power Apps Premium (Per-User Plan)

The per-user plan is a monthly license assigned to an individual user. As of this writing, it runs approximately $20 USD per user per month (Microsoft adjusts pricing periodically — always check current pricing in your region).

A user with a Power Apps per-user license can:

• Run unlimited Power Apps, whether they use standard or premium connectors
• Access Dataverse as a data source
• Build and publish their own apps (not just run apps built by others)
• Use Power Automate for standard flows triggered from Power Apps

Think of the per-user plan like a library card. Once you have one, you can access everything in the library. It makes the most sense for:

• Power users and citizen developers who build and use multiple apps
• Users who need access to several different apps across the organization
• IT and business analysts who are doing active development
• Small teams where the math works out favorably compared to per-app licensing

The per-user plan is generally the simpler administrative choice. You assign the license to a person, and they're covered for everything they build or run.

Power Apps per App Plan

The per-app plan licenses access to a specific number of apps, not a specific person across all apps. As of this writing, it's approximately $5 USD per user per app per month — though Microsoft has also experimented with a "pay as you go" model and capacity-based approaches for the per-app model.

A user covered by a per-app license can:

• Run the specific apps they've been allocated passes for
• Access premium connectors within those specific apps
• Access Dataverse within those specific apps

The per-app plan makes sense when:

• Most users only need one or two specific apps, not a broad portfolio
• You're deploying a purpose-built tool to a large frontline workforce (warehouse workers, retail associates, field technicians)
• You want to control access granularly — specific people get access to specific apps
• The math favors it — if a user needs access to three or more apps that all require premium licenses, per-user often becomes cheaper

Let's run the math on a realistic example.

Example: You're deploying an inventory tracking app to 200 warehouse workers. Each worker only needs this one app. They don't build apps, they just use this one.

• Per-app plan: 200 workers × $5/month = $1,000/month
• Per-user plan: 200 workers × $20/month = $4,000/month

In this case, per-app saves your organization $3,000 per month. The trade-off is administrative overhead — you need to manage app pass allocations — and the restriction that these users can only access the specific app(s) covered by their passes.

Now flip it: your finance team of 30 analysts needs access to five different Power Apps that all use premium connectors (SQL Server reporting, Salesforce pipeline data, expense submissions via SAP, etc.).

• Per-app plan: 30 users × 5 apps × $5/month = $750/month
• Per-user plan: 30 users × $20/month = $600/month

At five apps per user, per-user becomes cheaper — and the analysts can also access any future apps you build, with no additional licensing changes.

Tip: The break-even point between per-app and per-user is typically around three to four apps per user. If your users will need more than that, per-user is almost always simpler and cheaper.

---

Dataverse: The Special Case

Dataverse deserves its own section because it influences licensing decisions in ways that go beyond just "premium connector."

Dataverse (formerly called the Common Data Service, or CDS) is Microsoft's cloud-hosted relational database that's purpose-built for the Power Platform. It has enterprise features that SharePoint lists simply don't have: proper relational tables, role-based security, server-side business logic, API access, and deep integration with Dynamics 365.

When you use Dataverse as your data store, your licensing already needs to be at the premium tier (per-user or per-app). But here's the wrinkle: Dataverse storage capacity is not unlimited, and it's provisioned at the tenant level based on the number of licenses in your organization.

Each Power Apps per-user license adds a small amount of Dataverse capacity to your tenant pool. If you have a large Dataverse database with many records, you may need to purchase additional Dataverse storage capacity beyond what your licenses provide.

For most small-to-medium app deployments, this isn't a practical concern — your default capacity is usually sufficient. But if you're building a data-intensive application (think: an operations log that records thousands of transactions per day, or a customer database with millions of rows), storage capacity is something your IT department needs to plan for.

Tip: Dynamics 365 licenses (for Sales, Service, Finance, etc.) include significantly larger Dataverse capacity and also grant the right to build and run Power Apps that read from the same Dataverse environment — even at premium connector levels. If your organization already has Dynamics 365 licenses, check whether your Power Apps users might be covered already.

---

Developer and Trial Plans: Building Without Burning Budget

One thing that confuses beginners is the difference between building apps and deploying apps for users. Here's an important distinction:

You don't need a paid Power Apps license to build and test apps in your own developer environment.

Microsoft provides a Power Apps Developer Plan that is free and gives individual developers access to:

• A personal Dataverse environment
• Premium connector access for development and testing
• The ability to build and test apps with your own data

The developer plan is not for production deployment — apps in your developer environment can't be shared widely with other users. But it's perfect for learning, building, and validating your app before purchasing licenses for your user base.

There are also 30-day trial licenses for per-user plans that let you run a real pilot with actual users before committing to ongoing licensing costs.

Warning: Some organizations make the mistake of using the developer plan or trial for actual production deployment, assuming that the limitation doesn't apply to them. It does. Using non-production environments or trial licenses for real business operations is a licensing violation and creates risk — especially if an audit or renewal conversation surfaces it.

---

A Practical Decision Framework

Let's bring everything together into a step-by-step way to reason about licensing for any app you're building.

Step 1: Audit your connectors. List every data source your app connects to. For each one, check whether it's a standard or premium connector. If they're all standard — you're likely covered by Microsoft 365, and you can stop here.

Step 2: Count your users and their breadth of access. How many people need to use this app? Do they need access to just this one app, or will they be using (or building) multiple Power Apps?

Step 3: Apply the break-even test. If users need access to fewer than three or four apps, per-app is likely cheaper. If they need more, per-user is likely cheaper and simpler.

Step 4: Check for existing license coverage. Does your organization have Dynamics 365 licenses? Microsoft 365 E5 or certain business premium plans? Some of these include rights that may partially or fully cover your scenario. Talk to your Microsoft licensing contact or partner — this is an area where a quick conversation can save meaningful money.

Step 5: Plan for Dataverse storage if applicable. If you're using Dataverse, estimate your data volume and growth rate. Confirm that your license count provides enough storage capacity, or budget for additional capacity.

Step 6: Use trials and the developer plan for validation. Before purchasing licenses, pilot your app using trial licenses or your developer environment to confirm the app actually solves the problem before you've committed budget.

---

Hands-On Exercise

This exercise doesn't require you to build an app — it's a licensing analysis exercise based on a realistic scenario.

The scenario: You're a business analyst at a regional logistics company. Your operations manager has asked you to build a Power App for your 85 delivery drivers. The app needs to:

• Allow drivers to log delivery confirmations with a timestamp and customer signature
• Pull their daily delivery route from your company's Oracle database
• Send a confirmation notification via Outlook when a delivery is complete
• Store completed delivery records in Dataverse for the operations team to review

Your operations team (12 people) also needs a companion app to view delivery dashboards and manage routes. They'll be using Power Apps for this and two other apps the IT team is building.

Your task: Work through the decision framework.

1. Identify all connectors in both apps. Which are standard, and which are premium? (Hint: Oracle is a premium connector, Outlook is standard, and Dataverse is premium.)

2. Decide on a licensing approach for the 85 drivers. They only use the delivery confirmation app. Run the math on per-app versus per-user.

3. Decide on a licensing approach for the 12 operations team members. They use three apps total. Run the math.

4. Write a one-paragraph licensing recommendation that you'd present to your operations manager, explaining what licenses are needed and why.

There's no single right answer for the final recommendation — reasonable people can weigh administrative simplicity differently from cost. But you should be able to articulate the trade-offs clearly.

---

Common Mistakes & Troubleshooting

"I thought SharePoint connector was always free." SharePoint is a standard connector when connecting to SharePoint Online. If you're connecting to an on-premises SharePoint installation via the on-premises data gateway, the gateway itself requires a premium license. Always verify the connection type, not just the service name.

"We gave everyone a per-app pass but the app still won't open." Per-app passes need to be allocated to specific apps in the Power Platform admin center, and then assigned to users. Simply purchasing the per-app plan doesn't automatically grant access — an admin has to do the allocation. If users are getting access denied errors, check that the passes are properly assigned to both the app and the users in question.

"Our developer built the app with a premium trial license, but now it's expired and users can't access it." The app itself doesn't expire — the licenses do. Your users need active licenses to run the app. This is one of the most common "production emergencies" in Power Apps deployments: someone built something useful during a trial period, the trial ended, and suddenly the app stops working for everyone. Treat trial periods as pilots, and have a licensing plan ready before the trial expires.

"We have Dynamics 365 Sales — does that cover Power Apps?" It depends on the specific Dynamics 365 license and what you're doing with Power Apps. Dynamics 365 licenses typically include the right to build and run "model-driven apps" within the same environment, and they contribute Dataverse storage. But they don't always grant canvas app access with premium connectors at the broad level that a dedicated Power Apps license would. This is one to verify with Microsoft specifically.

---

Summary & Next Steps

Licensing is the part of Power Apps that most tutorials skip, and it's also the part that creates the most real-world friction when you're trying to deploy something useful. Here's what we covered:

• Microsoft 365 plans include seeded Power Apps access for standard connectors only — SharePoint, Outlook, Excel Online, and similar Microsoft services
• Premium connectors — including SQL Server, Salesforce, ServiceNow, Oracle, Dataverse, and custom connectors — require a dedicated Power Apps license
• The per-user plan covers unlimited apps and is best for active builders and users who need multiple apps
• The per-app plan is cost-effective for large groups of users who only need one or two specific apps
• Dataverse is both a premium connector and a managed service with storage capacity implications
• The Developer Plan is free and excellent for building and testing, but not for production deployment
• The key to good licensing decisions is auditing your connectors early, counting your users, and running the break-even math

Next steps in this learning path:

• Building Your First Canvas App — now that you understand the licensing landscape, you can design apps with an eye toward connector choices
• Introduction to Dataverse for Power Apps — a deeper look at when and why to choose Dataverse over SharePoint as your data backend
• Power Apps in Microsoft Teams — a special licensing scenario where apps embedded in Teams have different rules and access models

Licensing conversations are never exciting, but they're much better to have before deployment than after. Go build something — and now you'll know exactly what licenses to bring along.