Let's talk money

Power Platform licensing is explained in the Licensing overview for Microsoft Power Platform, and the Microsoft Power Platform Licensing Guide is the best source of information. Make sure you are using the latest version; the platform is changing constantly and the document is updated accordingly. Sometimes it's just clarifications, while at other times it may introduce a new licensing model, such as pay-as-you-go.

Licensing in a nutshell

Let's focus on the most common scenario:

• you are building a solution using Power Apps and Power Automate,
• the solution is accessing data in SQL database, and
• all users in your tenant have M365 licenses.

SQL connectors are premium, which means that both, the app and the flow will automatically become premium and will require additional licensing.

In this case, you have the following choices:

Power Apps

Power Automate

For our scenario, the only important part is Power Automate use rights included with Power Apps licenses. (For other cases, please consult the Types of Power Automate licenses for a summary of Power Automate licenses.)

The Power Apps Premium, Power Apps per app and Power Apps pay-as-you-go licenses include Power Automate use rights for workflows associated with Power Apps applications.

Power Automate use within Power Apps is limited to the context of the Power Apps application, which means that a flow included within a Power Apps application may connect to:

• Any data source within the use rights of the Power Apps application.
• Directly with the Power Apps application (via built in trigger/action).

See What Power Automate capabilities are included in Power Apps licenses?

Power Automate use within Power Apps application context ✅

A user with a full Power Apps license runs an app that uses a SQL database as the data source and includes flows that:

• Read from OR write to the SQL database.
• Use a built-in Power Apps trigger and/or action – e.g., sends a push notification to the app.

Power Automate use outside of Power Apps application context ❌

The same user (in the example above) now also wants to use a flow that updates an Oracle database, that:
• Is completely unrelated to the Power Apps app.
• Does not interact in any way with the Power Apps app (or its data sources).

If the flow is isolated and has nothing to do with the Power Apps application, then a full Power Automate license will need to be purchased.

Source: Microsoft Power Platform Licensing Guide

VIP (Very Important Powershell)

If a cloud flow (only) uses the same data sources as a Power App, you can link that flow to the app using a PowerShell script.
Usage is then covered by the user’s standalone Power Apps license or the Power Apps pay-as-you-go meter.

Add-AdminFlowPowerAppContext -EnvironmentName <String> `
    -FlowName <String> -AppName <String> `
    [-ApiVersion <String>] [<CommonParameters>]

^{3) Power Automate use rights included with Power Apps do not include RPA functionality, which requires a separate purchase of Power Automate Premium
4) Within app context}

Let's talk money💶

The Power Apps per-app meter explains in good detail the impact of app usage on the final solution cost.

Let's take their example and compare it with the Premium (per user) and per app (per user/per app) licenses.

If a user has a Power Apps per-user license, they aren't counted in the meter, I'm therefore considering each of this licensing models as an isolated case.

Case 1

The Premium (per user) and per app (per user/per app) licenses generate costs no matter if users are using the app.

Assuming that:

• we have a total of nine licensed users in our company,
• a total of 3 Power Apps application,
• all users are licensed to use all applications

the pay-as-you-go licensing is the cheapest options, generating savings during the months the applications are not in use.

Case 2

Let's license all the users in the company now, and see how the cost will change.

This time, we don't have "no usage" months but still, the "pay-as-you-go" licensing proves to be the most effective model.

Case 3

Can I "break it"? What would happen if each department used "their" application at least 1 time each month?

Getting there... the gap is closing.

Case 4

Ok then, let's make each licensed user access each of the applications at least once a month

I see... if all users are using all the apps each month, the pay-as-you go becomes the most expensive option.

Some thoughts on per user vs per app

Even though in the above examples, the "per user" licensing seems the most expensive, let's remember that we considered the cost for only 3 Power Apps.
Increasing the number of apps when using "per app" model will very quickly increase the cost.

In the diagram below you may see the impact that a small increase in number of apps, with relative low number of users will have on the total cost of Power App licenses.

...this is really complicated! 😅

One key takeaway is that thorough research and planning are essential. It’s crucial to assess expected workloads, evaluate licensing models, and collaborate with other teams to identify the most cost-effective approach.

I wonder what is everyone else doing❓
Is your entire organization licensed with the per user licenses, to minimize administrative overhead with tracking license usage?
Or perhaps you now start with pay-as-you-go which, as per Microsoft will help us "understand adoption patterns for new apps to determine whether prepaid licenses make financial sense for your business".

Care to share? 😀

Automatic Creation of Auto-claim Policies [Update 28.12.2023]

Starting in December 2023, Microsoft introduced Auto-claim Policies, which simplifies license management for administrators.

The "Auto-Created Policy for PowerApps" allows Power Apps per-user licenses to be automatically assigned to unlicensed users when they first access a Power App that requires a premium license.

It is available by default in managed environments. However, administrators can also apply it to standard environments via Power Platform admin center.