skip to Main Content

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.

Power Automate Flow Dataverse Trigger

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.

Power Automate Flow Invoker User

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.

Dataverse Act on Behalf of Another User security privelege

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.

Power Automate Flow Run As Experimental Feature

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.

Power Automate Flow

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

Power Automate Flow record owner

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

Power Automate RunAsSystemUserId

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

Power Automate created by

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.

This Post Has 8 Comments
  1. Excellent post – a lot of above is indeed missing from MS docs (as of now) so good to understand that.

    Just one question on experimental feature: this new dropdown seems lot similar to D365 (dropdown vs optionset). Is there any specific reason (aka benefit) of introducing this in Power Automate?

    1. Ali, the benefit is it gives you (without having to look into the datamodel) the numeric value that you can use to test with downstream. For example if you had CUD trigger, you could then easily use those value in a switch statement later on in the flow to determine what you might do with that specific action. Does this help?

  2. Probably a stupid question, but could this be used to trigger and run flows for users without a flow license?
    (I guess not!)

  3. Hello Jerry,

    These are superb articles. Thanks so much for doing it. I’m learning a great deal.

    May I ask a dumb question please? Let’s say we set the trigger to “Run As” and select the value to “Triggering User”. On the subsequent CDS actions we enable the “Use invoker’s connection”. One down stream action is to create a “Invoice” record, but our “Triggering User” doesn’t have that access to create an Invoice record. I would imagine the Flow would fail. Am I correct in thinking that?

    Thanks very much, and again, great job!

    Garry

  4. Hi Jerry –

    Wonderful article! We’re in the process of converting several of our SharePoint workflows into Power Automate to migrate to SharePoint online in a few months. We are really struggling with these API limits, as my coworker and I are building hundreds of PA workflows for high-volume SharePoints. Is there something comparable to this functionality using SharePoint connectors? I tried to add that trigger, but was unable to find it. Possibly because it’s a Premium (?) feature, and our company is only on the E3 license (2,000 API/day limit).

    Any guidance you can provide is greatly appreciated.

    April Crowell

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top