How to Configure Dataverse Application Users
What is an application user
In Dataverse, an application user refers to a specific type of user account created for use by an application or service, rather than by a person. Application users are used to perform specific actions in the system on behalf of a person, without requiring that person to be logged in. This allows for automation and integration with other systems.
The application users are free of charge, and don’t need a license, but are subject to API limits, like every other user.
So before talking about application users and how to correctly configure them, we have to talk about API limits in dataverse.
API Limits
There are two kinds of API Limits in dataverse we can call them Service Protection Limits and Entitlement or Commercial Limits.
Service Protection Limits
The service protection limits are made with the scope of keeping the number and magnitude of the requests for every user in the limit of the correctness of usage of the SASS service of Dataverse. Like every other service on the cloud Dataverse (and Power Platform in general) has high scalability but not immediate reactiveness. That’s why to keep the system running, the platform doesn’t allow a single user to overcome certain limits in terms of concurrent connection, the number of requests in a timeframe and the sum of the computational time of the request sent in that timeframe (on a single front-end instance).
In Dataverse those limits are listed here
As I am writing this blog article, the limits are:
| Measure | Description | Limit per web server |
|---|---|---|
| Number of requests | The cumulative number of requests made by the user. | 6000 within the 5 minute sliding window |
| Execution time | The combined execution time of all requests made by the user. | 20 minutes (1200 seconds) within the 5 minute sliding window |
| Number of concurrent requests | The number of concurrent requests made by the user | 52 or higher |
Entitlement Limits
The entitlement limits are evaluated in 24h and are specific to the license that the user has. These limits are only about the number of requests and are listed here.
At the moment the limits are:
| License | Requests per paid license per 24 hours |
|---|---|
| Paid licensed users for Power Platform (excludes Power Apps per App, Power Automate per flow, and Power Virtual Agents) and Dynamics 365 excluding Dynamics 365 Team Member1 | 40,000 |
| Power Apps pay-as-you-go plan, and paid licensed users for Power Apps per app, Microsoft 365 apps with Power Platform access, and Dynamics 365 Team Member2 | 6,000 |
| Power Automate per flow plan3, Power Virtual Agents base offer, and Power Virtual Agents add-on pack4 | 250,000 |
| Paid Power Apps Portals login | 200 |
But as we said before, application users don’t have any licenses, so what are the entitlement limits for them? The explanation can be complex, but I’ll try to simplify it a little.
There is a pool of requests that can be used by application users at tenant level (so for every environment created for a single company). This pool of requests changes if there is an assigned Dynamics365 license in the company or not. If there is the tenant has 500000 requests per day and for every license of Dynamics365 you’ll get 5000 requests more, up to 10 Million.
If your company has just PowerApp or PowerAutomate licenses the thing is simpler. You’ll get 25000 requests per day, period.
How many applications users we can/must create?
The creation of an application user is pretty straightforward nowadays (you can find instructions here), so I’ll explain here how to size the number of application user. The number of application users you need to create has to be sized keeping in mind the API limits to not be impacted by them.
Let’s do our math:
- Service protection limits are evaluated per user (and per frontend server): In this case, more user is better, I can split the load on multiple users, having less probability to overcome the limits.
- Entitlements limits are per tenant: In this case, the number of users is irrelevant, since given that we’ll need to perform X requests, making them with a single user or with multiple users, will count the same.
So the answer to the question is enough to do the job to not get throttled. But there are a few things to say.
How to configure them
Here is something that I found out based on my experience with multiple customers.
Application user means that it’s for an application
It’s easy to understand, but the thing is more complex than it seems. It’s better to have a pool of application users different for each application. This is for multiple reasons:
- You’ll probably have different teams to do the job, I rarely saw the very same team managing very different external application/integration for a customer
- If you enable the integration with Application Insight, you can query data starting from the userid performing the request. If you have a specific pool of users for a defined application/integration rather than a general-purpose pool, then you’ll be able to correlate the calls to a specific load.
- On a security level, giving the “System Administrator” role to application users is a problem. Since this is an unmonitored account and in general people/objects with the “System Administrator” should be as low as possible. But you cannot avoid it if you have a single general-purpose pool.
Some more words on the security role
I said that you should avoid giving the “System Administrator” role to an application user, and that’s true. The problem is that you should avoid giving the same security role given to your users as well.
The application users usually have higher permissions and need the best achievable performances, you should then avoid giving read permissions lower than “organization” (this topic deserves a blog post itself), and this is not something that you usually do for a security role used by interactive users. So the best advice here is to create an ad-hoc security role for the application user.