Minimum Privileges Required to Log in to Model-driven Apps in Dynamics 365/CDS

One of the security best practices in Dynamics 365 is to use the base security role as a baseline and apply that role to all Users. The base security role will include all the common/basic permissions that are required to have access to the system (you can read more details in  Tip #2 of Power Platform / Dynamics CRM  Tip of the Day). The advantage of using the base security role is to allow the administrator to add/remove privilege for all users by just updating the base security role instead of having to go through all the security roles. The base security role is different for each project depending on what the user with the minimum permission should be able to perform in the system.

🛈 Note

Microsoft has documented the minimum privileges for common tasks and you can download the Microsoft Dataverse minimum privilege security role from the Download Center. It can be used as the base security role in your system or can be copied to start your custom security role.

To set up the base security role for the first time
  1. create a new empty security role.
  2. add the minimum privileges required to access the system.
  3. add the privileges required for the basic functionalities.
  4. test the role with the test user account.
  5. add the permissions to the entities that all users can access (e.g. reference data).
If you are not sure what are the privileges required, step 2 and 3 can be time-consuming since those two need to be identified by trial and error. Microsoft has added a new standard role called Common Data Service User and that is the ideal role for your base role instead of the empty role in step 1. But that role has quite a lot of privileges for standard CDS entities and if your organisation requires a really strict base security role, it might be better off starting with an empty role.

In that case, there are a few old articles by Inogic and Goutam Das which contains the template for the base security role. This post will be similar to those two posts but I will try my best to describe why each of those privileges is required for each particular functionality. At that same time, I hope that will be helpful for those who are looking for the solution of a particular function not working well due to the missing privilege. (e.g. unable to run an on-demand workflow, Business Rule is not working, etc.)

In today's fast-paced Power Platform world, the structure of the security role keeps changing and more privileges are added in each major updates. My plan is to keep updating this post whenever there is an additional privilege added in the future updates which need to be part of the base security role. Please also leave a comment if you identify any privilege which is not part of the list below.

CDS and Dynamics 365 Privileges

So, what are the minimum privileges required to log in to the model-driven app?
- Read privilege to the Model-driven App entity. Voilà... You can log in to the model-driven app as long as the user has the security role with Organization level 🟢 prvReadAppModule.
But wait, prvReadAppModule is just the minimum privileges required to log in to the model-driven app. That does not mean the app will be functional only with that privilege. You will just see the Sitemap with Recent, Pinned, Dashboards, etc. clicking on any of those will just show an error page. These are the minimum privileges required to log in to the *functioning* model-driven app

The following table was last updated in July 2020 based on CDS version 9.1.0000.20151.

These are the hidden privileges and you do not specifically need to add in the security role.

Privilege Name Privilege Access Level
prvReadSharePointDocument Read Organization
prvCreateSharePointData Create Organization
prvReadSharePointData Read Organization
prvWriteSharePointData Write Organization

These are the privileges required to load the UI components of the model-driven app and they are all in the Customization tab of the security role form. And make sure the base security role has access to that particular model-driven app.

Privilege Name Entity Privilege Access Level
prvReadAttributeMap Attribute Map Read Organization
prvReadCustomization Customizations Read Organization
prvReadEntity Entity Read Organization
prvReadEntityKey Entity Key Read Organization
prvReadEntityMap Entity Map Read Organization
prvReadAttribute Field Read Organization
prvReadAppModule Model-driven App Read Organization
prvReadOptionSet Option Set Read Organization
prvReadRelationship Relationship Read Organization
prvReadSavedQueryVisualizations System Chart Read Organization
prvReadSystemForm System Form Read Organization
prvReadQuery View Read Organization
prvReadWebResource Web Resource Read Organization

The following privileges are required for some common basic functionalities in the model-driven apps as specified in the Required For column

Privilege Name Tab Entity Privilege Access Level Required For
prvReadUserSettings Business Management User Settings Read Business Unit Personal Options
prvWriteUserSettings Business Management User Settings Write Business Unit
prvCreateUserEntityUISettings Core Records User Entity UI Settings Create User Getting/Saving UI setting for the user such as Recent Items, Pin Items, etc.
prvReadUserEntityUISettings Core Records User Entity UI Settings Read User
prvWriteUserEntityUISettings Core Records User Entity UI Settings Write User
prvCreateUserQuery Core Records Saved View Create User Managing personal Saved Views
prvReadUserQuery Core Records Saved View Read User
prvWriteUserQuery Core Records Saved View Write User
prvDeleteUserQuery Core Records Saved View Delete User
prvAssignUserQuery Core Records Saved View Assign User
prvShareUserQuery Core Records Saved View Share User
prvFlow Customization Run Flows N/A Organization Running On-demand Power Automate flows and showing On-demand workflows in Unified Interface
prvWorkflowExecution Customization Execute Workflow Job N/A Organization Running On-demand workflows
prvReadWorkflow Customization Process Read Organization Business Process Flow, On-demand workflows, Business Rules
prvAppendToWorkflow Customization Process Append To Organization Business Process Flow, On-demand workflows
prvReadAsyncOperation Customization System Job Read User On-demand workflows
prvCreate*BPFEntityName* Business Process Flows *BPF Name* Create Organization Business Process Flow
prvRead*BPFEntityName* Business Process Flows *BPF Name* Read Organization
prvWrite*BPFEntityName* Business Process Flows *BPF Name* Write Organization
prvAppend*BPFEntityName* Business Process Flows *BPF Name* Append Organization
prvAppendTo*BPFEntityName Business Process Flows *BPF Name* AppendTo Organization

Dynamics 365 Specific Privileges

The privileges above might be enough for the model-driven app in the CDS but in Dynamics 365, there are some system scripts which query certain data in the backend. Some of those WebAPI calls will fail silently but some may throw a generic error as below in Unified Interface.
You do not have {0} permission to access {1} records. Contact your Microsoft Dynamics 365 administrator for help.

In that case, open the Developer Tools of the browser and check the descriptive error in the Network tab (with Result "Forbidden" / Status "403" errors) to find out which privilege is missing. You can read more about deciphering the Unified Interface generic permission errors in this blog post by Alex Shlega.

The descriptive error message will say that the user is missing prvActionEntity. If you are not sure where that privilege is located in the security role form, one of the methods is to check this old Dynamics CRM 2016 documentation. I am not sure why "Security role UI to privilege mapping" is no longer included in the Dynamics 365 Customer Engagement (on-premises) documentation or Power Platform documentation. If you see the privilege but not sure if it the prvActionEntity specified by the error message, you can open up the Developer Tools of the browser and inspect the element (Ctrl + Shift + C in Chrome) to see the backend privilege name.

You can also identify those scripts which fail silently due to the missing privileges by checking the error lines in the Network tab of the browser's Developer Tools. Another alternative way is checking the network request details in the recently announced monitor tool for model-driven apps.

Here are some examples of the privileges required by the system scripts.

Privilege Name Tab Entity Privilege Access Level Required For
prvReadOrganization Business Management Organization Read Organization Dynamics 365 environment with Microsoft Teams integration Script Error for Web Request: /api/data/v9.0/organizations(xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)?$select=ismsteamsenabled,ismsteamscollaborationenabled
prvReadUser Business Management User Read Business Unit System script to read azureactivedirectoryobjectid of current user Script Error for Web Request: /api/data/V9.1/systemusers()?$select=azureactivedirectoryobjectid&$filter=systemuserid%20eq%20xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
prvReadSdkMessage Customization Sdk Message Read Organization System script to read SDK Message Names Script Error for Web Request: /api/data/v9.0/sdkmessages(4c53ccbd-bbfa-4aad-a725-ffba2246d683)?$select=name
prvReadRoutingRule Service Management Routing Rule Set Read User System scripts for routing rules Script Error for Web Request: /api/data/v9.0/routingrules?$filter=msdyn_entitylogicalname%20eq%20%27ENTITYNAME%27
prvReadmsdyn_PostConfig Custom Entities Post Configuration Read Organization System scripts for activity feed Script Error for Web Request: /xrmservices/2011/OrganizationData.svc/msdyn_PostConfigSet?$select=msdyn_EntityName,statecode&$filter=msdyn_EntityName%20eq%20%27ENTITYNAME%27
prvReadActivity Core Records Activity Read User System scripts in Omnichannel for Customer Service Script Error for Web Request: /api/data/v9.0/msdyn_ocliveworkitems?$filter=_regardingobjectid_value%20eq%20%27xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx%27%20and%20statecode%20ne%203%20and%20statuscode%20ne%204


  1. It's worth saying that the Error code you are looking for in the Network tab of the Developer Tools is for Forbidden / 403 errors.

    I would also say that all the security roles listed are required - I suspect you would get some very interesting support requests that would take a long time to debug if one of those roles were missing.

    1. That should (of course) read all the security privileges listed are required for the role..

    2. Thanks for the feedbak eek, I have updated the blog post to add "Forbidden / 403 errors" around network tab part.


Post a comment

Popular posts