Power Platform - request limits / best practices / cluster risk?

[LimeLeaf]

Hi Power Apps Community,

lately i reviewed the June 2021 licensing guide for the Power Platform producs.
I stumbled over a view sections where the total api request per user are picked up e.g.

I digged a little bit deeper in this topic and the ms documentation regarding this and i came up with the following page and table.
(https://docs.microsoft.com/en-us/power-platform/admin/api-request-limits-allocations)

As far as i understand this documents  - basically there are limits for each user how many api calls are allowed in regards to their licensing. But at the moment there is no way even for ms to measure these api calls, especially when these apps and flows are not somehow related to the dataverse. (please correct me if i am wrong :))

In our organisation our power automate and power apps number is increasing monthly and at the moment we are working with a total number of about 40 flows and a hand full of apps. The largest peace of the cake (95%) of our flows and apps are running under a centralized service user. Here my question arise: some of the flows are really API intensive - that is nothing i can measure at the moment but i think i can deviate this with my common sense. (E.g. the flow got a lot of flow steps and is running every 3 seconds or is even triggered in a shorter time period)

In regards to that and after reading the following i got a little bit nervous:
(https://docs.microsoft.com/en-us/power-platform/admin/api-request-limits-allocations)

We are blessed with a dynamics license so as i understand the request limits we have a bout 20000 api requests avaiblable within 24h for each user equiped with this license. 

I see a cluster risk here when you have a centralized service users who is running a ton a flows and apps. Especially because (as i understand) there is no way to measure where you stand with the individual users api requests. So i decided yesterday to outsorce some of the api intensive flows to other users to keep our service user save for all the other flows. 

Is there a best practices to measure api calls of non dataverse apps/flows? Is there a best practice how to handle this topic?
Is there a special user type in place which has an even higher limit of api calls for centralized service users?
Am I overthinking this topic? 😉 

Kind regards,
LimeLeaf

[joe_hannes_col · Accepted solution]

Hello @LimeLeaf,

The connectors we can use in the Power Platform are using web services to connect to the different systems. If you use an action from a connector, the connector makes an API call to this web service. Hence, basically every step you perform in a Flow or Power App is an API call. Maybe this helps estimate the number of API calls your flows are going to make.

If you want to find out the number of requests by a specific flow, you can use the "Analytics" functionality in the flow's details:

And yes, there are special types of user that has access to a tenant-wide pool of API calls: https://docs.microsoft.com/en-us/power-platform/admin/api-request-limits-allocations#requests-limits...

Are you using Dynamics 365 Enterprise or Business? In the case of Enterprise, your tenant entitlement for these types of users would be 100,000 requests daily, or 50,000 requests if you use Dynamics 365 Business.

In your case, you could use a non-interactive user account, for example.

[LimeLeaf]

Hi @joe_hannes_col,

your information really helped my out, thanks a lot! 

We are using Dynamics 365 Enterprise - is it possible to change the user type of an application user to an non-interactive user? And in case yes, can we still log in with a non-interactive user to manage the flows and apps that are owend by the non interactive service user? 

[LimeLeaf]

It would be great to have a overview somewhere in the admin center where you can check the current assigned API call limit by each user and the corresponding total use of this api calls for each user. This would make the overall monitoring and understanding of this topic much easier. 

Or is there already something in place like this?

[LimeLeaf]

We created a non-interactive user and tried to assign a flow to this user. As described here (https://docs.microsoft.com/en-us/power-platform/admin/create-users#create-a-non-interactive-user-acc...) a non-interactive user has no licencsed assigned to him so he is not capabale of beeing the owner of a power automate flow. As I understand the non-interactive users now these are only used in the S2S communication. 

So the only option to use the tennant wide API Call limits with a power automate/flow owner is a administrative user? (https://docs.microsoft.com/en-us/power-platform/admin/create-users#create-a-non-interactive-user-acc...) Can someone confirm this or is there any other solution/best practice?

[LimeLeaf]

Is there no solution for running api intensive flows with the tenant wide api call limits? 

[pabloperalta]

Hi @LimeLeaf 

sooner or later Microsoft will enforce those limits. I actually faced similar enforcement when calling some new PBI APIs from Power Automate.

So, it’s a smart practice to proactively tackle that as you’re doing.

Now, in the case of intensive flows and given they can be handled by a non interactive account, have you looked at Logic Apps instead?

Hope it helps,

PP

[LimeLeaf]

Hi @pabloperalta,

that's exactly what I'am expecting they will enforce those limits. 

For the moment it seems like it is the best option to have multiple "normal" users to distribute the api calls.
Each of them equiped with a adequate license.

Never heared about MS Logic apps i will have a look at it. Thanks! 🙂

Kind regards,

LL

[pabloperalta]

Thank you.

I would definitely do @LimeLeaf. You'll find it pretty familiar and the limits are much much higher.

You may need to calculate costs, as in Logic Apps you pay based on Azure consumption, it's not per user or app.

But indeed, at first glance, it looks like that's the move that you need.

Regarding multiple "normal" users, I personally wouldn't think that's the way to go. It requires refactoring your workflows anyway, will be hard to maintain and there is no warranty it'll be sustainable in the (near) future.

Just my 2 cents.

Thanks

PP