Controlling access to information is a key requirement that every CRM product on the market needs to address. It is important to ensure that every CRM user should only be able to see the information that they are authorised to see.

Dynamics CRM comes up with many different features in this regard and access is controlled primarily using the following

  • Security roles
  • Field security profiles
  • Access teams
  • Record sharing

In this blog we will look at the record sharing feature that CRM users end up using for their incidental security requirements. For example, when a temporary team/role is identified within an organisation and it needs access to certain records, it is common approach to share those records with them with varied levels of access. Another situation that this is applicable is when a user is going on leave and the person needs to delegate their CRM chores to someone.

As users learn to use CRM, they become accustomed to the convenience of record sharing because they do not need to wait for the IT team to change the security role configuration. However, record sharing comes with a trade-off, and if not governed properly, it has the potential to degrade system performance.

With the growing popularity of Dynamics CRM Online, it has become even more important to understand the impacts of record sharing because Dynamics CRM Online customers pay for the amount of disk usage, and record sharing directly impacts the database size.

The purpose of this article is to take you behind the scenes and show you how record sharing affects the PrincipalObjectAccess table which stores all your sharing related information. I will divide the blog into three parts as defined below

Part 1 – Introduction to PrincipalObjectAccess table (this article)

Part 2 – PrincipalObjectAccess table – Sharing with users and teams

Part 3 – PrincipalObjectAccess table – Sharing with access teams


PrincipalObjectAccess table

As described earlier, this table inside the Dynamics CRM database stores all the record sharing information, i.e. what records have been shared with which users and with what level of access.

The below table describes the structure of PrincipalObjectAccess table.

PrincipalIdThis is the GUID of the user, owner team or access team with which the record is shared.
PrincipalTypeCodeA unique code of the principal with whom the record has been shared
ObjectIdThis is the GUID of the actual record that has been shared.
ObjectTypeCodeA unique code of the entity whose record has been shared
AccessRightsMaskThis represents a cumulative value of the level of permission with which the record has been shared.

This represents a cumulative value of the level of permission with which the a child record has been shared due to cascading.

Below is a screenshot of the PrincipalObjectAccess table

principal object access table record sharing


In the next blog (Part 2), we will see how this table is impacted when records are shared with users and teams.