Principal Object Access Table n MSCRM 2011

Principal Object Access Table

POA (principal object access) table is a table for sharing of records. The shared, assigned and re-parented or inherited records are added to this table. Basically if you try to access a record that you do not own the system will check the POA and if the permission is there then you can access the record.

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 column 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 column 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 column 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.