Power Automate Flow – Controlling Microsoft Dataverse API Assignment

In a previous blog – Power Automate Flow Consumption Limits I covered one of the most misunderstood components of which user gets charged for API calls for asynchronous flow runs (hint: it isn’t the user’ whose account is used for the connection credentials).

In this post I am going to explain how you can implement a more granular control of which user account gets charged for Microsoft Dataverse CRUD API calls.

Take a look at the Trigger below which is available to you when you are building a flow within a solution.

I have highlighted one of the advanced options – Run as. There isn’t much information online on what this does. So, besides the obvious – set this to one of the three choices and then it appears it will use that user account. But what does that mean?

What this means is the selection made in the Run as drop down will override the assignment of the flow API calls rule where instead of all the subsequent CDS actions defaulting to the process owner (a fancy name for the owner of the flow which unless something special is done is always the creator/maker of the flow)

Step 1 – Select the Record Owner or the Triggering User. Hint: Triggering User would be the user that gets recorded in the Modified by field.

Part 2 – For each Microsoft Dataverse action that you want to run as the Run as selector, go to the … Menu at the top right of the action card and select Use invoker’s connection stetting. For those action cards (steps) where the ‘invoker’ is not selected, the flow owner would be allocated the API call. Remember from the previous blog, it doesn’t matter whose Connection reference is used.

Part 3 – A few important notes and one very important prerequisite.

A. Delegate privilege – The ability for the maker of the flow (process owner, flow owner) to use the invoker’s connection setting is based on this user being assigned the Delegate privilege – (prvActOnBehalfOfAnotherUser) – Which is the Act on Behalf of Another User setting in Business Management tab.

B. Team Owned records? – What happens when you select Record Owner in the Run as and the record owner is a Team? Well then in that case it is identical to when a Team owns a flow (that will be covered in an upcoming blog). In both cases a ‘team’ is treated like all non-users, the API calls will come out of the tenant pool. FYI – The tenant pool is where those identities that do not require any user license to interact with the service – Application users, Non-Interactive users, Administrative users and the SYSTEM user get their API call allotment.

C. In the first screen shot in the blog post, you see the drop down for Run as when you are using powerautomate.microsoft.com in the ‘production’ mode. However, if you are in the Experimental Features mode it will appear as follows. This will be the new look going forward as it presents the display name and the logical value. For drop downs it then gives you a value that you may want to use later on in an expression/formula.

Practical Usage

So now the question is why might we want to use the Run as selector. I can think of a couple of good reasons, if you have more to add, please make a comment to the blog post.

A. Visibility and Tracking – Microsoft Dataverse records get acted on and created with the ‘right’ user information. So instead of every downstream CRUD action causing the created by, owner or  modified by field to be filled in with the user that owns the flow, in many cases it would make more sense for it to be done in the name of the originating record. This is perfect in the case of child records where there is a security setting or view that either restricts the user to only seeing records they own or a view that returns “My ‘records’ ” so that they get the. And then in this case there is some automatic symmetry between – created by, modified by and owner.

B. API Allocation – Consider you have a lot of flows in your environment that run for the overall benefit of the entire organization. It may be quite likely that the combination of the work of all those flows to exceed the tenant level API allotment even when it is 100K in a 24 hour period. Configuring flows that ‘distribute’ the API calls based on whose records they are acting on could be a strategy to spread the API usage out throughout the user base and not get into a throttling scenario for your non-interactive accounts.

A brief example of the practical  usage concept.

We have set the trigger to Run as the record owner and then the companion step is to use the invoker’s credentials in the action to create a task.

When this flow runs you can check your results  by inspecting the record created in Microsoft Dataverse or looking inside the flow actions. Here we can see that the system user who is the owner of the triggering record is charged for the flow and is also the creator, owner and the modifier of the new task record.

The output from the trigger which shows that user 1602….. owns the triggering record

and will be charged for any downstream actions where the action has been set to invoker.

The output from the action to create the task that shows user 1602…. is both the creator and owner of the new record.

Summary

There is a lot more that we will need to understand about these limits so we can apply them in a manner to get the most out of the API call allocation. Kind of feel we are at point 1 in a 10 point learning curve.

PS.

There isn’t a Product Team docs.microsoft.com article on this just yet. But when it is published I will update this blog post with the link.

Thanks to fellow BizApps MVPs Antti and Elaiza for reviewing this post before it went live.