Viewing all CRM Privileges, including hidden Privileges

Our guest blogger today is CRM MVP David Jennaway, the technical director of Excitation Ltd, a Microsoft Gold Partner in the UK that specializes in delivering Microsoft CRM solutions.

Authorization in CRM is controlled via security roles; a user is made a member of one or more roles, and receives the privileges associated with those roles. The privileges associated with a role can be viewed and modified via the tabs on the Role form:


Although this form displays a lot of potential privileges, there are a few hidden privileges within CRM that are not accessible via the CRM user interface. The built-in security roles in CRM are granted the relevant hidden privileges, but these privileges will not necessarily be granted to custom security roles. If you create a custom role from scratch, it will not receive any hidden privileges, whereas if you copy a role, then the new copy will receive the hidden privileges associated with the role that was copied. However, when viewing a role in CRM, there is no visible information about which (if any) role it was copied from.

Where the role and privilege data is stored

All roles and privileges are stored in the MSCRM database, and can be accessed most easily via custom reports. Relevant data is stored in the following tables and/or views:


Table or View




One record for each role a user is a member of



One record for each combination of role and business unit



One record for each privilege held by a role (equivalent to an icon on the role form)



One record per possible privilege



Link table to relate a privilege to an entity



Metadata table, with one record per entity

Note that users only have SQL permission to access the filtered views directly. Those entities listed above as tables have no associated filtered view can only be queried if the SQL Server database owner grants permission on these objects. Also, it is not supported to directly access these tables, so their structure may be changed without warning; I have no qualms about reading data from these tables, but I would never consider modifying data directly in these tables.

Two columns need further explanation to help interpret the data in these tables: FilteredPrivilege.AccessRight. This identifies the action the privilege applies to:



















Although the bit values could allow one privilege to be associated with more than action, this never happens in CRM.

RolePrivileges.PrivilegeDepthMask. This indicates the level of the privilege:






Business Unit


Parent: Child



It is worth allocating privileges to one of two categories; entity privileges and miscellaneous privileges. Entity privileges necessarily apply to a specific entity, and separate privileges are required for each action (e.g. Create, Read). Miscellaneous privileges are most easily categorised as privileges that do not relate to one of the standard 8 actions on an entity. It is worth noting that some miscellaneous privileges do apply to a particular entity (e.g. prvPublishArticle), and some don’t (e.g. prvExportToExcel)

Reporting on privilege data

I’ve create some Reporting Services reports to access all privilege data, and these reports are available on the MSDN Code Gallery at

Miscellaneous privileges

The first report (MiscellaneousPrivilegesByRole) displays a matrix, allowing comparison of miscellaneous privileges between roles. This can be used to illustrate the issue with hidden privileges that was described earlier. The following output shows two roles, the built-in System Administrator role, and a custom role ‘Granted all Privileges via UI’ which, as named, was created as a blank role, but was then granted all privileges available in the CRM user interface. For space reasons I’ve only displayed the first 20 or so privileges.


Here you can see there are several differences, which are not apparent via the CRM user interface.

Entity Privileges

The second report (EntityPrivilegesByRole) displays all entity privileges in a similar way to the CRM user interface. This illustrates another point about privileges; that not all entity privileges are displayed in CRM, and that there are hidden entity privileges. Here are the first few entity privileges for the System Administrator role:


And here are those for my custom role:


Although the privileges for the more common entities (e.g. Account, Contact) are the same, there are some discrepancies in other entities, e.g. BusinessUnit and CustomerRelationship.

It should be stressed that not all of these privileges are used by CRM, and many of the hidden privileges will have no effect on your CRM system. However, these reports do allow you to drill deeper into the actual privileges than you can via the CRM user interface.

Summing up

There are some subtleties around the CRM privileges, especially as not all privileges are visible via the CRM user interface; however the privilege data can be accessed via SQL reports. When creating a custom role, it makes a difference whether you create the role from scratch, or whether you copy an existing role – you only get the hidden privileges if you copy an existing role with those privileges.

It is possible to programmatically access and change the hidden privileges via the CRM platform, using the AddPrivilegesRole, RemovePrivilegeRole and RetrieveRolePrivilegesRole messages, though this will require some development work.

Additional resources

Source for the reports illustrated in this article:

Knowledge base article listing hidden privileges, and the built-in roles they apply to:

CRM 4.0 SDK Appendix A, listing roles and privileges:

CRM 4.0 SDK information about the role entity, and messages for programmatically changing privileges:


David Jennaway

Comments (11)

  1. Scott Sewell says:

    Nice one David! –

    Another one that would be interesting is a net-effective security for a user – sum up the priviledges for a user based on the total of all their roles.

  2. Ahmad says:

    Thanks for the article, David. This will surely help developers (and others) understand Roles better.

  3. Scott

    I’m intending to produce the privileges by user – the SQL is pretty similar. If I do I’ll publish the extra reports on the MSDN Code Gallery resource (same link as in the article)


  4. Scott

    I’m intending to produce the privileges by user – the SQL is pretty similar. When I do I’ll publish the extra reports on the MSDN Code Gallery resource (same link as in the article)


  5. I’ve added reports by user to the resource on the MSDN Code Gallery –

    ps Sorry about the previous double post. Oops

  6. says:

    Great writing, made me understand a thing or two 😉

  7. Dominic says:

    Can anybody answer this question? : Is it possible to programmatically share records in CRM? Having to go into a record -> actions -> sharing and then select team/ user lists is too much to be a reliable process. Thanks

  8. Microsoft CRM Solutions says:

    Microsoft Corp. has released an Open Letter from Michael Park, corporate vice president, sales, marketing and operations, Microsoft Business Solutions, inviting customers to learn about and evaluate Microsoft Dynamics CRM Online.

  9. sonia says:

    I saw a amazing website where you can get brockage free properties means u can save a lot money by using this website……Freedalal. com is provide you facility of brockage free property in all over india….realy its a amazing website…

     Its a fastest property showing website….

  10. Roy says:

    Hi Guys,

    It seems that the code has been archived in MSDN and is no longer available..

    Can anyone share it somehow?



  11. Srinivas says:

    Hi David,

    The link is not accessible. Is their a new link from where this can be downloaded?



Skip to main content