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