Power Automate Flow Consumption Limits
If you are a flow maker then you must become very familiar with the request limits and configuration limits for the product. If you aren’t then you are at risk of your flowing failing or getting throttled.
The two key pages for this info are at:
In the last few days there have been some critical updates to the Request limits and allocations page to clearly explain which account is ‘charged’ for the API calls.
It has been well misunderstood and a source of confusion for many regarding who is charged – the flow owner, the user that invokes the flow or the user account used for the connections.
I want to be totally and absolutely clear for everyone reading this post. The credentials of the user account being used for the action will not be the user account that is charged with the API calls. This is the source of most the confusion.
With the addition of the following FAQ item it should be clear to all (finally) that the API calls are charged as follows.
What account’s limits are used for classic workflows or Power Automate flows?
“It depends if the process is run on-demand or in the background. Instant flows, which are run on-demand, will use the limits of the account who started the process. On the other hand, workflows or automated/scheduled flows that run in the background will always use the limits of the owner of the process irrespective of why the process started or what accounts are used for connections inside of the process.”
And straight from Stephen Siciliano, the Microsoft Power Automate Czar
“If it’s triggered in the background, e.g., on a schedule or based on a cloud event – then it’s from the owner’s limits.
If it’s triggered on-demand, e.g., from a Power App, then its from the person triggering it’s limits.”
This Post Has 7 Comments
thanks Jerry – informative. For automated/async flows, how about Application Users, which to my knowledge cannot own flows? While the connection may well specify the Application User, how does that account get charged against the tenant wide pool if that account cannot own the flow?
Rob,
Application users (or all non-interactive accounts) can definitely own a flow.
Jerry
Dear,
I would very thankful if you could provide me with next information. Jerry, since you wrote that Application users can own the flow, does that mean that API call consumption will be executed against application user? If that is case what would be limitations per action than?
Do you have any knowledge how to create flow as an application user? Is there such possibility since they do not use username and password?
Thank you for your time.
Best regards,
DZ
Yes if we could make the owner of a flow the service principal user account it would be charged against the 100K API daily entitlement for that user. However, after months of waiting it is still not possible to over ride the original creator/owner of the flow either via the UI or by code.
Yes, I manage to assigned principal user account as a only owner, but still on the flow details user who created flow is shown as an owner. I was not even sure who flow than is executing API call consumption. Thank you for response. I guess I can only use principal user to connect to Dataverse inside flow, to which I will have some benefits.
Since I do not have permissions I am not able to try it, but I am curious would it be overridden if we deleted/deactivated flow creator user from Office 365?
Thank you very much for your response.
Best regards,
D.Z.
Hi there, for automated flows, does the “Run As” option not make a difference?
So I can understand if the flow limits are taken from the owner when the “Run As” is set to “Flow Owner”, but surely it shouldn’t be taken from the owner when the “Run As” is set to “Modifying user” or “Row owner” in the case of Dataverse?
Barry – see this docs article. https://docs.microsoft.com/en-us/power-platform/admin/power-automate-licensing/types#whose-power-platform-request-limits-are-used-by-the-flow