[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
- Licensing basics for Microsoft Flow
- Licensing Basics for Microsoft PowerApps
- Licensing changes to Microsoft Flow and PowerApps in February, 2019
- Verifying current license usage
- Verifying On-Premises Data Gateway usage
- Removing Custom Connectors
- Frequently Asked Questions (FAQ)
- In summary
The purpose of this post is to offer a comprehensive look at how Microsoft Flow and PowerApps 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 Flow and PowerApps.
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 if you could reach out to me via Twitter (my DMs are open) or via email at firstname.lastname@example.org.
Licensing basics for Microsoft Flow
Flow 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
- Flow Plan 1, for $5/user/month allowing more runs per month and the use of Premium Connectors
- Flow Plan 2, for $15/user/month, allowing even more runs per month and organizational policies (among other small features)
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 Flow, 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 Flow license (and thus, access to Flow creation and consumption).
Licensing basics for PowerApps
As with Flow, PowerApps requires a license for each user who needs to create or access PowerApps solutions.
PowerApps can be licensed in the following ways:
- PowerApps 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’
- PowerApps Plan 1, for $7/user/month allowing for use of Premium Connectors and creation of apps that employ Common Data Service for Apps
- PowerApps Plan 2, for $40/user/month allowing for model driven apps as well as multi-stage processes (among other features)
- PowerApps 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!] PowerApps Plan 2 for Dynamics 365, which includes the ability to run standalone applications and less limitations on use rights – see details here
You can review the detailed licensing and capabilities here.
Bottom line for both Flow and PowerApps is that you either use the free license as part of Office 365, or purchase any number of Plan 1 and Plan 2 licenses, per user. 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. Start with the free plans, and go to P1 for power users that absolutely require premium features.
Licensing changes to Microsoft Flow and PowerApps in February, 2019
In late 2018, Microsoft’s Chris McNulty announced updates to both Flow and PowerApps 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 PowerApps 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 PowerApps license will have to be purchased – and these are naturally per user per month.
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 in 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 PowerApps – 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 PowerApps 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 extension has been made for a given tenant.
During this time customers must figure out a correct path from either of the following options:
- Retrofit or re-architect the Flows and PowerApps 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.
- Purchase the necessary P1 or P2 licenses 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 PowerApps 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 for 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 how the initial Flow is being executed.
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 current 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 PowerApps 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 PowerApps Admin Center to review user licenses
PowerApps (and Flow) has a separate Admin Center at https://admin.powerapps.com, that 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 PowerApps 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 PowerApps solution that you can import via PowerApps 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, PowerApps for Admins, PowerApps 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 with the latest license change.
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 PowerApps 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 PowerApps and Flow configuration data:
Authenticate with a Global Admin account, or a similar administration account that has permissions for both PowerApps and Flow Admin Centers.
Next, query for environments:
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:
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 it’s 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 date 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 PowerApps 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 PowerApps 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 a HTTP request is received” trigger), as to clean them up or purchase the necessary amount of licenses?
Answer: 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]:
Answer: 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 turns 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 a 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 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?
Answer: 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?
Answer: No. Licensing for Power BI does not change in this context.
I’ve always loved Flow and PowerApps. Since their inception a few years ago I realize I’ve used Flow massively in many projects, and often I get to use PowerApps 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 PowerApps 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 a 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.
I help organizations create secure cloud and hybrid solutions using Microsoft Azure and Office 365. I’m a Microsoft Most Valuable Professional & Microsoft Regional Director. Based in Helsinki, Finland.