Power Automate Flow API Calls – How are they counted

In a previous blog post I explained how Power Automate flow API calls are ‘not’ assigned to a connection and how they can be distributed to other users besides the owner of the flow.

You should familiarize yourself with the other two posts before going forward in this blog where I will explain how and when API calls are counted.

There are three rules to understand where and how, and how many API calls are incurred by a flow you have created. Once you understand these rules you will be able to use this knowledge when you architect the flow and implement the design pattern.

• Rule #1 – One flow action or trigger consumes one API call.
• Rule #2 – See Rule #1 most of the time.
• Rule #3 – On occasion a flow action could consume more than one API call.

And you thought it would be easy-peasy? Almost. Let’s get started.

NOTE: I have illustrations of a few of the rules at the end of the blog in case you are not familiar with the listed design pattern.

First off let’s make sure we have the lingo correct – a ‘card’ in flow can be a ‘trigger’ or an ‘action’ or a ‘control’ – essentially anytime you see one of these rectangular items in the UI – its a card, regardless of whether you think it performs any real action.

Let’s go over Rule #1 which is a rather simple, direct statement yet perhaps a perplexing statement. Here are some practical examples for Rule #1.

1. A flow card that is a Dataverse CRUD call doesn’t count as two API calls only one.
2. No matter how complex the expression is and how many expressions are in a card, the card only counts as one API call.
3. No matter how many dynamic content fields are used in an action or how many different action cards are referenced is irrelevant also, the card consumes only one API call.
4. Action cards in an apply to each loop count once each time they are looped through.
5. Action cards that are not ‘traversed’ during a flow run don’t consume an API call.
6. If you set concurrency to >1 then each card traversed when performing their ‘concurrent’ action will consume one API call.

Now Rule #2 – basically for most of us, most of the time, for most of the flows we create that is all we need to do – apply Rule #1- . But there are a few outliers where you could have a situation where an action card could generate more than one API call. That brings us to Rule #3

Rule #3 – On occasion a card could itself generate or as a result of it’s action, many API calls.

1. Pagination – on occasion you may need to use pagination to process a lot of records. When you set the pagination it will help you manage the volume of records that need to be processed. Each time there is a pagination iteration, it will consume one API call.
2. Retries – if you set the  Retry Policy to deal with intermittent failures then each retry will consume an API call.
3. Apply to each – this was kind of covered in Rule #4-4 above but not only do you have to consider that each card in the loop generates an API call, the Apply to each card also consumes a API call once for each loop.
4. Do until – this design pattern is like the Apply to each. As the Do until goes through it’s Count before reaching the time out there will be one API call consumed for each loop plus one API call for each card inside the loop.

Illustrations

Rule #1 – 1 – Here we have a flow action card that is also a Microsoft Dataverse CRUD action – Create. The two actions zero out and only one API call is charged to the account.

Rule #1 – 2 – Courtesy of fellow MVP Antti Pajunen this is an example of a Microsoft Dataverse CRUD action – Update with several complex expressions. Although there are what appear to be several API calls in play, the card only consumes one API call.

Rule #1 – 4 – In the illustration below, the flow is retrieving all the flows in the tenant and then for each flow it found, creating a row in Dataverse with information about that flow. So if it found 50 flows, there would be 100 API calls charged, one for each For each flow found looping through and one for each row created therefore 2 actions x 50 loops = 100 API calls.

Rule #1-5 In this illustration since the condition evaluates as no, only the actions inside of the no action consume API calls. The yes branch is not traversed so it doesn’t consume any calls.

Rule #1-6 Setting concurrency will cause this action to run in parallel batches 20 at a time. Therefore this card will consume 20x the number of API calls in parallel rather than in series. No difference but a different way of thinking of it.

Rule #3-1 & 2 In this settings illustration Pagination has been turned on (although the threshold hasn’t been specified) and a Retry Policy is being defined. Both of these settings will result in multiple API calls to be generated by this card.

Rule #3-4 This is the illustration to show that a Do until card is similar to how an Apply to each is calculated for API calls. In this logic step the process will loop through and  perform the record update until the condition was satisfied or the count of 60 had been reached. So for each Do until there will be one API call for the Update record card and one API call for the Do until. The result will be 120 API calls.

The post Power Automate Flow API Calls – How are they counted appeared first on CRM Innovation - Microsoft Dynamics 365 Consulting and Marketing Solutions.