One of the topics of discussion that can come up during the planning phase for a customers CRM implementation is Business Unit structure and sharing, which leads to the PrincipalObjectAccess (POA) table. As the POA table grows in size due to the sharing of records, which can be frequent in environments with a complex Business Unit structure, CRM performance can suffer. Below are some general recommendations that we provide to customers that are anticipating their deployment will have a complex Business Unit structure and/or frequent sharing of records.
Not all of these will be applicable to all deployments but the goal of most of these is to provide customers items to consider while they are planning out their Business Unit structure.
Thank you for the valuable information in this post. I have a question though; you mention "Modify Security to allow users to see information outside of their Business Unit".
Can you elaborate on that? Do you mean changing user role access level or something else?
You are correct where possible based upon business requirements if you can change the roles so that users have organization access that would be ideal and allow you to reduce the amount of sharing taking place.
Thanks for the article. Our organization has a very large PrincipalObjectAccess table and I have been unable to figure out why. We have only two teams - the built-in one and our custom one - and we only use our custom. We don't prevent sharing between records, everyone can see everyone else's records. We only have one business unit - and yet our PrincipalObjectAccess table is huge. Any idea why and how we can bring it down in size?
How large is the large amount of POA table? In may case the table size is around 3 GB and index space is double than that. I also have a performance issue with CRM where closing case will sometimes takes quite a long time or even failed. Any idea?