The comprehensive licensing guide to Microsoft Power Automate (formerly Flow) and Power Apps

The comprehensive licensing guide to Microsoft Power Automate (formerly Flow) and Power Apps

NOTE: I’ve joined Microsoft, and will no longer update this guide after December 16th, 2019. This is both because my role within Microsoft isn’t geared towards licensing, and also because I feel the guidance on the Power Platform licensing becoming more clear and transparent.

[Last update: November 27, 2019: Many updates; New recap section in the beginning; Additional considerations; Cleaned up certain old and irrelevant content; More clarity for Power Automate and Power Apps per app plans. I’ve also created a helpful visualization of the licensing options!]

[Last update: July 25, 2019: I’ve added a new section on the upcoming and major licensing changes due October 2019]

[Last update: June 22nd, 2019: I’ve added more details on multiplexing and connection pooling as it relates to licensing, and also some additional thoughts on the ramifications of the license change.]

[Last update: Jan 31st, 2019: I’ve updated bits and pieces with additional details and clarification – I’ve marked those with a timestamp in the guide]

In 2006 I applied to work at Microsoft, in their Dublin, Ireland office. I was offered a job and moved immediately to Ireland from Finland. On my first day, I was handed a respectable pile of paper by my manager with links to all the internal and external tools I’d be needing in my job. On the last page someone had scribbled:

“NEVER discuss licensing unless LCA is involved!”

For those not versed in the internal Microsoft jargon, LCA stands for Legal & Corporate Affairs. They were serious folk, for sure. I took this advice to heart, as frequently I would field questions at conferences and workshops on the optimal approach to purchase a license for a given service or software. I got very good at deflecting those questions to LCA. Sorry, LCA people – and thank you for helping out during my years at Microsoft (I left in 2009 to find my own company).

So, when I started writing this post these memories came flashing back to me. I realize I am still not a lawyer, and I still haven’t internalized all the numerous Microsoft licensing programs, options, restrictions, and benefits. And probably never will.

Table of Contents

The purpose of this post is to offer a comprehensive look at how Microsoft Power Automate and Power Apps can and must be licensed. This is especially crucial now when Microsoft is changing some aspects of the licensing based on specific technical use cases. I trust a guide like this will help others who need to figure out the correct licensing model for Power Automateand Power Apps.

If after reading this guide you’re still in doubt, always check with either your Microsoft Partner Account Manager or license reseller.

I will be updating this guide when there are notable (and sometimes not so notable) changes, that I feel are inevitable in the age of SaaS. If you find an error or feel I’ve misunderstood something and can provide clarification, I’d appreciate it if you could reach out to me via Twitter (my DMs are open) or via email at jussi@roine.fi.

Updates in late 2019

I first wrote this guide in early 2019 with the intention to make licensing of Power Apps and Flow more approachable. I spent numerous hours dissecting the licensing details, talking with people who knew about licensing, and trying to transform the complex into simple. I’ve updated this guide a few times during 2019, and now with the latest changes in late 2019, it’s time to update this guide again. Certain bits are not valid anymore, so I’ve tried to mark those as deprecated or irrelevant as best I can.

In late 2019, Microsoft announced during the Ignite conference that Microsoft Flow is renamed to Power Automate. You can view the presentation from Ignite here. Besides a mere name change, Power Automate also received numerous updates – new Robotic Process Automation capabilities knows as UI Flows; better bot capabilities (known as Power Virtual Agents), just to name a few.

I’ll aim to use Power Automate when I refer to the service now, and in the future. I’ve kept Flow as a reference, when I’m referring to the past – such as changes announced in February 2019 and October 2019, as they related to the name at the time.

Meanwhile, in October, licensing also changed for both Power Apps and Flow (now: Power Automate). The license seemed to include two major changes: the move to per app license model, and additional changes to existing capabilities.

PowerApps also seemed to be renamed to Power Apps. Subtle difference.

Licensing basics for Microsoft Power Automate (formerly: Flow)

Power Automate is licensed in one of the following ways:

  • As part of Office 365 with Microsoft Flow for Office 365 – this is a free license, allowing for a limited number of Flows to be run per month. This free license has the least amount of capabilities – it excludes access to Premium connectors, for example.
  • Flow Plan 1, for $5/user/month allowing more runs per month and the use of Premium Connectors. Note, that you can only purchase this plan before April 1st, 2020. After this, it won’t be available – unless your tenant already has one or more of these licenses.
  • Flow Plan 2, for $15/user/month, allowing even more runs per month and organizational policies (among other small features). Note, that you can only purchase this plan before April 1st, 2020. After this, it won’t be available – unless your tenant already has one or more of these licenses.
  • Power Automate per user plan, for $15/user/month, allowing a user to create and run business processes
  • Power Automate per flow plan, for ~$500/month including 5 flows, allowing a power user to create a solution that departments can then easily use. The purpose of this plan is that individual user licenses are covered in the context of the business process solution.

In addition, Dynamics 365 plans include a Microsoft Flow for Dynamics 365 plan, and a few Dynamics 365 plans include the Flow Plan 2 listed above. To see the full chart on what plan gets which Flow plan, see here. I anticipate this table to be refreshed after February 1 to reflect the licensing changes (see below).

Each user in Office 365 has to be licensed for Power Automate, one way or another if they want to benefit from Flow. You don’t have to license all users in your tenant, just the ones that will be granted a Power Automate license (and thus, access to Flow creation and consumption).

Licensing basics for Power Apps

As with Power Automate, Power Apps requires a license for each user who needs to create or access Power Apps solutions.

Power Apps can be licensed in the following ways:

  • Power Apps for Office 365, almost identical to Flow for Office 365 as in it’s included as part of most Office 365 plans and is thus considered ‘free’
  • Power Apps Plan 1, for $7/user/month allowing for use of Premium Connectors and creation of apps that employ Common Data Service for Apps. Note, that you can only purchase this plan before April 1st, 2020. After this, it won’t be available – unless your tenant already has one or more of these licenses.
  • Power Apps Plan 2, for $40/user/month allowing for model-driven apps as well as multi-stage processes (among other features). Note, that you can only purchase this plan before April 1st, 2020. After this, it won’t be available – unless your tenant already has one or more of these licenses.
  • Power Apps per user plan, for $40/user/month, enabling users to create and run business applications
  • Power Apps per app plan, for $10/user/app/month granting use rights for a specific, custom business application
  • Power Apps for Dynamics 365, which includes all capabilities from PowerApps Plan 2 but access is restricted to Dynamics 365 entities and APIs
  • [Update Jan 31st, 2019 –thanks @jukkan!] Power Apps Plan 2 for Dynamics 365, which includes the ability to run standalone applications and fewer limitations on use rights – see details here

You can review the detailed licensing and capabilities here.

The bottom line for both Power Automate and Power Apps is that you either use the free license as part of Office 365 or purchase any number of Plan 1, Plan 2, Per User or Per App licenses.

From now on I’ll refer to P1 and P2 when I mean Plan 1 and Plan 2.

You can, and probably should mix and match licensing to your organization’s needs.

Licensing changes to Microsoft Power Automate and Power Apps in October 2019

Every time I feel I’m done with this licensing guide, Microsoft decides to change or update the licensing model for Power Apps and Power Automate! I’m not complaining, but announcing two licensing updates within one calendar year makes it challenging for customers to plan for the future.

During Microsoft’s Inspire 2019 in mid-July, there was a session on Power Apps and Flow licensing model changes. You can find the session here, but it seems it won’t be made available for streaming.

To put this short, changes to Power Apps and Power Automate licensing options will become effective in October 2019. This means that the four new app plans will be available:

  • Power Apps per app plan
  • Power Apps per user plan
  • Power Automate per user plan
  • Power Automate per flow plan

Power Apps per app plan (PAPAP for short, I just invented this) allows specific users to run Power Apps-based apps for a specific business scenario.

Power Automate per business process plan (PAPBPP) is not restricted to a specific user but rather provides capacity for a team, business unit or similar group of people.

To complicate things a bit further, PAPAP is also available per user, so it will be called Power Apps per user plan (PAPUP). PAPAP, the per app plan, will be priced at $10 user/app/month. PAPUP, the per user plan, will replace Power Apps P1 and P2 plans and will be priced $40 user/month.

The upside for this change is that both PAPAP and PAPUP licenses will include all features and capabilities. No more guesswork needed to figure out whether a P1 or P2 license is needed if you use a specific capability of the platform (such as Common Data Services-based entities).

Office 365 (and Dynamics 365) subscriptions will keep their existing “with Office 365” licenses, thus the non-Premium-licenses of these two cloud platforms will remain as-is.

Both PAPAP and PAPUP licenses include the new Power Apps Portals feature. Note, however, that the licenses only cover internal users who access the Power Apps Portals, not external users (either anonymous or authenticated). For external users, a separate Power Apps Portals license is needed: for authenticated external users this will be $200 / 100 logins/month, and for anonymous external users this will be $100 / 100,000 web page views/month.

For Power Automate, it’s the same story – licensing will be available as per user plan ($15 user/month) and per business process plan ($500/business process/month, with a maximum of 5 active workflows). At the same time, the older limits for trigger frequency and a number of Flow runs will be removed. An additional 5,000 daily API request capacity limit is also introduced, so this follows the Power BI licensing model.

In essence, the new plans (PAPAP and PAPUP for Power Apps, and PAPBPP and PAPBUP for Power Automate) aim to clarify the complexities of the Power Platform licensing. The P1/P2 licensing change controversy from February probably acted as a lightning rod for this new change also. Effectively, companies that choose the per user plan for either Power Automate or Power Apps will not need to worry about what they can do with their license as most or all capabilities should be at their disposal.

Administrators who need to have access to admin views in Power Automate, Power Apps and Common Data Services do not need a license. Further administration, such as specific Sales and Marketing modules requires a purchased license.

Licensing changes to Power Automate and Power Apps in February 2019

In late 2018, Microsoft’s Chris McNulty announced updates to both Flow (later it was renamed to Power Automate) and Power Apps licensing. You can read the original, and later updated announcement here.

In essence, effective February 1, 2019, a few of the most useful capabilities in Flow and Power Apps will require the purchase of a P1 or P2 license. Instead of using the ‘free’ license that organizations get as part of Office 365 plans, a separate Flow and Power Apps license will have to be purchased – and these are naturally per user per month.

Note, that you can only purchase P1 and P2 licenses before April 1st, 2020. After this, they won’t be available – unless your tenant already has one or more of these licenses. This is due to the newer Per App/Per User plans that were announced in October 2019 that will supersede the older Premium licenses.

The following three features will require the additional license (P1 or P2, depending on the exact need):

  • Custom connectors – creation and publication. This, in essence, means that if you create a custom connector, that provides capabilities beyond the regular connectors, additional licensing is required. A custom connector would be logic wrapped as Azure Function, or Logic Apps, or Azure API App – or something similar that exposes a custom logic through a common API layer.
  • HTTP custom actions used in Flows outside SharePoint Online and OneDrive for Business. If you need to construct custom HTTP calls to Microsoft Graph, and similar external (to Office 365 and its default set of connector) services, you are typically using the built-in HTTP connector. This connector will become a Premium Connector on February 1, 2019, and from thereafter requires a P1 or P2 license. More on this below.
  • Any integration from on-premises (and external data) that requires the use of On-Premises Data Gateway capability. The On-Premises Data Gateway is the very same component that Power BI and a few other services use and it’s typically deployed to an on-premises server. This way you can surface and connect to internal data from Flow and Power Apps – and this capability will thus require the additional P1 or P2 license. Note: this does not affect or change any licensing requirements for scenarios where Power BI is being used to access on-premises data with the same gateway.

For Flows and Power Apps apps that already employ any of these capabilities (as they’ve been freely available as part of the ‘free’ Office 365 license bundle), customers will get an automatic extension of using these for free up to January 31, 2020 – so exactly one year. Note: There does not seem to be a way to verify whether such an extension has been made for a given tenant.

During this time customers must figure out a correct path from one of the following options:

  1. Retrofit or re-architect the Flows and Power Apps solutions to not rely on any of the Premium capabilities the additional licensing is required for. Essentially, re-work through all Flow and PowerApps solutions so that they do not require any of the three major capabilities listed above.
  2. Purchase the necessary P1 or P2 licenses and continue without modifying any of the solutions
  3. Purchase one of the per app/per user plans and continue without modifying any of the solutions

If you find yourself in a situation where currently you are not using any of the three capabilities listed above, but know you will be needing them, Microsoft Support provides an escalation path for the extension. This extension runs for a year, and the request for escalation has to be made before April 30, 2019. So, if you’re reading this between late January 2019 (when this guide was initially published) and April 30, 2019, you can request for the escalation. Starting from May 1, 2019, the only option is to purchase the additional licensing if you need any of the three capabilities.

You might now be wondering how many P1 or P2 licenses you have to purchase if you have any amount of actively used Flows or PowerApps solutions in place. Before delving deeper into this subtopic, let’s first clarify one thing.

[Update Jan 31st, 2019: provided more clarification and phrased it to be more clear that this refers to Flows requiring P1/P2, not just any Flow]

For any Flow that uses capabilities that the license update affects, that is being triggered outside SharePoint Online requires a P1/P2 license for the author and all users benefiting or accessing the Flow. One scenario that is typical and which is affected heavily with the license update is when you have a Flow that uses a Custom Connector, and is executed through the Flow app on a mobile phone – then P1/P2 licensing is needed.

The same applies to Power Apps solutions. It’s worth clarifying here that users who benefit from Flows that use premium features, but that are invoked through SharePoint, do not require P1/P2 licensing. The author does require a P1/P2 license in a scenario like this – which I think is quite typical.

As an example of a scenario where all users would need to be licensed for P1/P2, consider a Flow that is used to capture status updates for reporting and invoicing.

Users trigger the Flow from a mobile app, fill in a status update as text and then trigger the Flow. This Flow connects with an internal HR system and stores the status data. All users who use this Flow would require a P1/P2 license because the internal HR system requires a Custom Connector (and the Flow is not triggered via SharePoint/Office 365).

A Flow becomes premium and requires a P1/P2 license at least for the author when it uses Custom Connectors, gateways, Premium Connectors or HTTP actions. In any mix where these are used, a P1/P2 licensing is required – at least for the author, possibly for users also, depending.

A Flow calling another Flow also uses the HTTP Trigger, and at least for now it seems a P1/P2 license model is required – for the author, once again depending on how the initial Flow is being executed.

Multiplexing and connection pooling

[Update: June 22, 2019: Added this section for clarification.]
One approach to optimizing or outright circumventing license requirements is multiplexing and connection pooling. These terms often mean the same thing — routing requests through one entry point, that then makes repeated or multiple calls to another resource. Hence, multiplying endpoint calls with the intention to only use one or more limited amount of resources (or licenses, in this case).

This will not reduce the number of required licenses for Flow and Power Apps. As both services require a license to access, the use of multiplexing and/or connection pooling is a circumvention of this license model. Subsequently, pooled connections (such as one centralized API that then calls APIs) must be properly licensed regardless of the intrinsic technical approach to access the API. A lengthier explanation of this can be found from Microsoft.

Visualization for licensing options

I spent a bit of time and tried to visualize the numerous licensing options that are now available. This is done in late 2019, so it conforms to the current guidance and practices for licensing.

To view the image in full size, click here.

Verifying current license usage

Now that we know what exactly is required, we need to verify how many licenses we actually need. At times, when I meet with license resellers, the intellectually boring option they lash out is to “just buy one for each user and maybe a few extras!” If you’re in the Casino & Space Travel business this might work out quite well but for all other companies struggling with budgets, it’s not reality.

To make things easier, we’ll use PowerShell to retrieve the currently available licenses, allocated licenses and finally the licenses we might be needing.

[Update Jan 31st, 2019] The PowerApps and Flow team has published a collection of scripts that allow you to review the usage of custom connectors, premium connectors, data gateway, HTTP actions – see here.

Note: Some of the Power Apps and Flow PowerShell cmdlets state you will need a paid P2 license to run them. I’m not using a P2 license to execute the following scripts, but obviously, if you do, you might want to sign up for a trial P2 license here.

Using the Power Apps Admin Center to review user licenses

PowerApps (and Flow) has a separate Admin Center at https://admin.powerapps.com, which reveals data policies, user licenses, and quotas. You can download a list of active user licenses here, as well as see if you’re hitting your quotas.

The resulting list is a .csv file, which you can easily format in Excel to suit your reporting and verification needs.

Using Power Apps to verify if Custom Connectors are used

An easy way to verify license usage for a tenant is to download the Connector Browser Tool from Microsoft. It’s a free Power Apps solution that you can import via Power Apps and quickly view what settings and connectors are in use.

Simply import the package and run it. You’ll need to grant permissions for Office 365 users, Flow management, Power Platform for Admins, Power Apps for Admins, Power Apps for App Makers and Microsoft Flow for Admins in order to see meaningful data. If you’re unsure of these permissions, open the app in design mode first to review what the app actually does.

When you run the app, it’ll show you all the environments, as well as all the API calls for quick access to your data. I found this particular tool highly useful, as the PowerShell cmdlets are sometimes poorly documented and not all too clear on what type of data you’re actually getting.

The app opens by default with Get-AdminEnvironments:

Select the desired environment – typically anything that is named after your organization and does not contain “Sandbox”, “Contoso” or “Test” in the name. Capture the Name of the environment and then click Get-AdminConnectors. Paste the environment name and submit. This will now list all custom connectors used in an environment:

As you can see, one of my environments has two custom connectors – one for retrieving weather, and another for something. These two connectors fall in the P1/P2 licensing scope, or the newer Per App/Per User licensing scope.

Using PowerShell to verify if Custom Connectors are used

If you have multiple environments, or simply prefer using a command-line and scripting approach, the very same approach works with PowerShell also.

First, install the recently updated Power Apps Admin and Maker modules. This includes Flow cmdlets also. Run this in an elevated PowerShell session:

Install-Module -Name Microsoft.PowerApps.Administration.PowerShell
Install-Module -Name Microsoft.PowerApps.PowerShell -AllowClobber

Then, we’ll authenticate against Office 365 to further access the Power Apps and Flow configuration data:

Add-PowerAppsAccount

Authenticate with a Global Admin account, or a similar administration account that has permissions for both Power Apps and Flow Admin Centers.

Next, query for environments: 

Get-PowerAppEnvironment

This should return a collection of one or more environments. You can query for custom connector against just one environment:

Get-AdminPowerAppConnector -EnvironmentName $env

Or you can query all environments for custom connectors: 

Get-AdminPowerAppConnector

Within the Internal field there’s a property named isCustomApi, which is set to True if your Custom Connector is, in fact, a Custom Connector.

The benefit of using PowerShell here is that it also shows you where the Custom Connector is hosting its precious business logic. In my case, the Get Weather Custom Connector is an Azure Function, thus the originalSwaggerUrl points to an Azure resource.

Verifying On-Premises Data Gateway usage

If you’re not sure whether any On-Premises data is being consumed through On-Premises Data Gateway, the quickest way to verify this is through PowerApps Admin at https://web.powerapps.com/environments/ENVIRONMENT/gateways. Replace ENVIRONMENT with your Power Apps Environment ID (the same one you used in the examples above).

In case you don’t have gateway instances deployed, you’ll see this:

Otherwise, you’ll get a list of all instances with details on which apps and solutions are employing the gateway:

From here, it’s easy to retire any unused gateways. You should probably not delete any gateways that are in use, as these will inevitably render any solutions relying on on-premises data as broken. You can view the connections that have been made through a gateway by clicking Details > Connections:

Removing Custom Connectors

If you need to remove the usage of Custom Connectors, the easiest way is to do it through the PowerApps Admin interface at https://web.powerapps.com/environments/ENVIRONMENT/customconnectors. Replace ENVIRONMENT with your PowerApps Environment ID (the same one you used in the examples above).

You can verify the owner, and all technical details for Custom Connectors here (in a given environment). You can also simply remove any Custom Connectors that are not needed anymore. Keep in mind that by removing it, certain Flows and Power Apps solutions will break.

If you need to verify which solutions are using a given Custom Connector, click on Connections and then open any of the connection instances of a Custom Connector. This reveals all solutions that are using the Custom Connector through a Connection.

Frequently Asked Questions (FAQ)

Question: How do I know which Flows are being triggered through HTTP (ie. “When an HTTP request is received” trigger), as to clean them up or purchase the necessary amount of licenses?
For now, there isn’t a tool from Microsoft that would reveal this easily.

Question: How can I call Microsoft Graph without using the HTTP Request (and thus requiring a P1/P2 license – at least for the author)?

[Update: Jan 31st, 2019]:
When accessing Office data from Microsoft Graph through Flow (by using the pre-made actions such as Get my profile, Get user profile, etc.) additional licensing is not required. This is due to being in the realm of Office 365/SharePoint Online, and as such, additional licensing is not required for regular Flows.

All other scenarios, where you would use a custom connector (to construct Microsoft Graph queries through a proxy or a wrapper), the HTTP action and similar would elevate the Flow to become a premium Flow. This, in turn, requires – since Feb 1, 2019 license updates – a P1/P2 license for the author, if the Flow is executed through regular means (such as when a list item is added to an SPO list). If the Flow is executed by users directly, such as through a PowerApp solution or a button somewhere, all users then require P1/P2 licensing. And of course, the author always needs a P1/P2 license if the Flow requires any features that demand this.

Question: Can I offload my business logic to a Logic Apps and thus avoid the P1/P2 licensing requirement?
Yes, and no. Calling a Logic App from PowerApps (or Flow) would be akin to calling a Custom Connector, thus the licensing change will affect these scenarios as well.

But if you trigger your Logic App through other means, then it would be an option. Keep in mind that Logic Apps entails other costs also and you might not have a direct means of executing a Logic App similarly to what you typically do in Flow.

Question: Do I need additional licensing if I use the On-Premises Data Gateway with Power BI?
No. Licensing for Power BI does not change in this context.

Question: Just wait! I’m confused. Which do I need – Office 365 license (such as E1 or E3), Power Apps or Power Automate P1 or P2 license, one of the Per App or Per User licenses or what?
Great question! Let’s try to make this simple.

If you only need to build basic Power Apps or Power Automate-based flows, any Office 365 license (per user) is good and often enough.

If you need any of the premium capabilities, such as custom connectors, the HTTP connector, fetching data from on-premises, accessing many of the Azure services – you’ll need either a P1/P2 license (before April 1st, 2020) or one or more Per App/Per User licenses.

There are, of course, edge cases that are hard to answer without knowing the exact details and variables involved.

In summary

I’ve always loved Flow/Power Automate and Power Apps. Since their inception a few years ago I realize I’ve used Flow massively in many projects, and often I get to use Power Apps as well. I’ve waited with a slight fear when Microsoft will start changing the licensing model for both of these platforms.

I’m not in the know what exactly drove the licensing change for Flow and Power Apps but I can only guess. It will be interesting to see how this reflects to Flow and PowerApps usage in the coming months, as many customers simply have not budgeted a P1/P2 licensing investment on top of their existing Office 365 licensing costs. Many customers I work with have an E3 plan in Office 365 and that’s all they are willing to purchase.

I’m hopeful for Flow and PowerApps, but I’m sure many times solutions will be built with Logic Apps instead of Flow, and SharePoint instead of PowerApps due to these licensing changes.

[Update June 22nd, 2019: It’s been a few months since this license change was put in place. I’ve yet to hear too many customers complaining about this – but then again I haven’t conducted a vast survey on this either. Several people have reached out to me privately and it seems many companies have built massive Flows (and some PowerApps solutions) that have been hit with these requirements. For those I’ve suggested to either re-architect their implementation (especially if purchasing a Premium license isn’t a realistic option) or switching to Logic Apps, when possible.]

[Update: July 25th, 2019: With yet another licensing model change due October, things will get more clear but also a bit more unclear. The new plans effectively replace the P1/P2 licenses, up the prices but abolish the differences between licenses. This is a good thing, but the price also goes up drastically at the same time. It remains to be seen in the next few months leading to October if there are going to be more changes and specifics on all the plans.]