Many of my customers have wanted clarification on the quotas for Microsoft Flow for the various license levels we have. This post will attempt to clear up any confusion.

Overview

The licensing page for PowerApps and Flow lists some quotas and limits depending on your license level, and can be a bit confusing. This post will attempt to clarifiy how exactly these quotas work in combination with particular license levels. Any specific numbers listed here may change over time, so they are valid as of the time of this initial posting (6/27/2018). I will keep the post updated if any of these numbers change, but as usual, you should refer to the official licensing page for the most current figures.

Maximum Flow Frequency

This limit creates the most confusion with my customers. The maximum flow frequency defines the shortest period of time that an automated flow trigger is allowed to check for changes. This maximum is based on the license level of the user who last edited and saved the Flow. Since flows run usually without any direct user interaction, there is no prompt for credentials when a Flow runs, so the Flow ends up running under the context and license level of the user who last edited and saved the Flow.

For Office365 Enterprise level licenses, this maximum frequency is currently 5 minutes. So this means that for any connectors that use a trigger that fires automatically, the test/check for the trigger’s condition (e.g. item created, row inserted, item updated, etc.) will only take place a maximum of once every 5 minutes for O365 E-level licenses.

This does NOT mean that instances of a Flow cannot be run more frequently than that. It just means that the check for the trigger condition will not occur more frequently than the max flow frequency. If the trigger check detects multiple changes in the backend system, it can start one instance of the Flow for each detected change immediately. Then the trigger polling mechanism will go to sleep and stop checking for changes again until the max flow frequency has passed.

Let’s look at an example for the SharePoint Connector, checking for items created in a list (but you can easily substitute rows in SQL Server connector, Tweets in Twitter connector, files added in DropBox connector, etc.). In this example, we are assuming the user that last saved the flow has an E3 license level (so a 5 minute max flow frequency):

• Flow has a SharePoint connector, with a Trigger on a SharePoint list for when Items are Created.
• The trigger runs at 1:10PM, and detects no changes. No workflows are started. The Flow goes to sleep and will not check again for the max flow frequency (5 minutes in this case)
• At 1:12PM, 4 new list items are created in SharePoint.
• At 1:15PM, the trigger check is again performed. 4 new items are discovered, so 4 new workflow runs are immediately started concurrently, one for each item.
• Next check for changes will occur at 1:20PM.

Notice in this example that when multiple changes are detected, workflow runs are spawned immediately for each change and run concurrently, they are not queued up, they do not stack up and have to wait for the max flow frequency to pass for the next run to execute. The max flow frequency simply drives how often the trigger conditions are checked for.

It’s interesting to note that you can control how many concurrent runs are started when the trigger fires. Most of our 1st party and 3rd party triggers use a polling system, where Flow checks the system regularly for changes. Most of these systems also have a way to return an array of changes in a single check. If you go into the Settings for a trigger (pull the ellipsis … down next to the Trigger and choose Settings), you may see a SplitOn section if the system is able to send back multiple changes with a single trigger change request. SplitOn determines the field in the trigger response that contains the array of items that has changed. You may also see a Concurrency Control section. If a system sends back an array of changes in response to a trigger check, you can control how many instances are spawned concurrently. Leave it off if you want to spawn as many as possible.

SplitOn and Concurrency Control in a trigger’s settings.

Automated Triggers

Automated triggers are subject to the maximum flow frequency. Automated triggers include the Scheduled trigger, and any other triggers not listed below in the Manual Triggers list.

Manual Triggers

Manual triggers are not subject to the maximum flow frequency. Manual triggers include the following:

• PowerApps trigger
• HTTP Request trigger
• Flow Button for Mobile

You can start as many flows as you wish, as frequently as you wish, using the manual triggers.

Maximum Flow Runs

The other quota your Flows will be subjected to is the Maximum Flow Runs per Month. Pretty straightforward – this controls how many instances (“runs”) a particular user is allowed to start in a given month. For O365 E-level licenses, this is 2000 runs per month per user. However this limit is pooled across the tenant, so if one user has reached the maximum, and another user has hardly used any, the unused runs will start to be consumed until the entire pool for all users in the tenant is exhausted for that month. If you start to hit the limit, you can purchase additional blocks of 50,000 runs for $40 USD / month.

Maximum Custom Connectors

The last quota to be aware of, which affects PowerApps as well as Flow, is the maximum number of Custom API Connectors that a user can create. With the O365 E-level licenses, a given user can only create a maximum of 1 custom API connector. This does not have anything to do with how many custom connectors can be used or referenced within a PowerApp or Flow, it’s simply how many custom connectors a given user can create. A Connector is a wrapper around an API or a service. A Connection is an instance of a Connector being used inside of a PowerApp or Flow. The limit here applies to the creation of the Connector– once it’s created, any Flow or PowerApp author can create Connections using the Connector without limits.

If you plan on needing multiple custom connectors created (maybe to be consumed in multiple PowerApps or Flows), then you’ll either need to distribute the creation of these across your developers, or you’ll need to purchase and assign a P1/F1 or P2/F2 license to the user that defines/creates the custom connectors.

Summary

Hopefully this post has helped to clear up some of the confusion around Flow licensing. If you have any other questions, please post a comment!