PrincipalObjectAccess–Performance Recommendations


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.

  • Share only what is needed
  • Minimize the number of Business Units where possible
    • Help reduce the need for sharing records
  • Ensure users are placed in the appropriate Business Unit
    • Can a user be moved further up the Business Unit hierarchy to give them the necessary access to records in another Business Unit
  • Modify Security to allow users to see information outside of their Business Unit
    • This will also reduce the need for sharing
  • Once a record does not need to be shared any longer, stop sharing it
  • Enable the EnableRetrieveMultipleOptimization registry key
  • Ensure frequent queries that involve the POA table have appropriate indexes in place

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.

- John

Comments (7)

  1. Marc Opheikens says:

    Hi John,

    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?

    Thanks,

    Marc

  2. Hi Marc,

    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,

    John

  3. Dave Mackey says:

    John,

       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?

    Thanks,

    Dave

  4. Erry Handani says:

    Hi John,

    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?

    Thanks,

    Erry

  5. Sharan says:

    Hi Jhon

    Did you get any answer for this . please post so that it will be helpful for others.

  6. balaji says:

    Hi John,

    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?

    Thanks,

    Balaji

  7. balaji says:

    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?

    thanks
    Balaji vecham

Skip to main content