Dynamics CRM in the Field

Information from the Microsoft Dynamics CRM PFE team working in the field

Excessive PrincipalObjectAccess Table Growth in CRM 4.0 from the Reparent - Cascade All Setting

Excessive PrincipalObjectAccess Table Growth in CRM 4.0 from the Reparent - Cascade All Setting

Rate This
  • Comments 2

I often times work with customers that enter a large number of records inside their Microsoft CRM system.  When reviewing their CRM table counts, they sometimes find that they have a larger than expected number of records in the PrincipalObjectAccess table (POA).  The POA table is used to provide access to specific records for CRM users, and each record in the POA table represents one CRM object that is related to one CRM user.  Records created in the POA table come from one of four ways:

  • Share reassigned records with original owner:  CRM System Settings
    • If this is set to Yes, then records would be added to the POA table whenever an assign takes place.  These records will have a value in the AccessRightsMask colum of the POA table.
  • Direct sharing:  Actions – Sharing 
    • When users explicitly share a record to another user, a record would be created in the POA table.  These records will have a value in the AccessRightsMask colum of the POA table.
  • Reparent Setting:  Relationship Behavior
    • Each entity has relationships with other entities (ex. Account to Case).  By default, the Reparent option is set to Cascade All.  With this setting, sub records would be shared to the owner of the parent record.  For example:  Let’s say that User1 owns Account1.  User2 has access to Account1 and creates a case underneath Account1.  With the out of the box Reparent options, a record would be created in the POA table that would give User1 access to the newly created case.  These records will have a value in the InheritedAccessRightsMask colum of the POA table.
  • Indirect Sharing
    • When sharing occurs through a direct share, assignment, or parenting, if the relationship is set up to cascade the share to child records, additional records will be created in the POA table in order to give proper permissions to the new user for the relevant child records.  These records will have a value in the InheritedAccessRightsMask colum of the POA table.

The Reparent setting is what seems to come as a surprise to some customers.  Many customers will keep the Reparent setting set to Cascade All.  This is a perfectly acceptable setting, but if the majority of your users already have access to the records that are being shared to them through their security role, the records in the POA table may not be providing much of a benefit.

It is possible to change the Reparent setting to Cascade None.  In this scenario, records would not be auto-created in the POA table for the owner of the parent record.  Building off of the example mentioned above:  User1 owns Account1.  User2 has access to Account1 and creates a case underneath Account1.  With the relationship set to Cascade None, a record would not be created in the POA table for User1.

Ultimately, you'll have to do some work to find out if you have any scenarios where users need access to records through the Reparent setting that wouldn't otherwise be provided to them through their CRM security role. 

- Jon

  • What would the effect be to truncate the table, would the access be recreated? Or should we rather look at how the entities are created and change the relationship accordingly

  • I can re-parent sharing none BUT how to clean up existing data which is already created in POA because of cascade share all.

Page 1 of 1 (2 items)
Leave a Comment
  • Please add 1 and 8 and type the answer here:
  • Post