Best Practices for Optimizing Sharing Performance

For an in-depth guide to this area, see Designing Record Access for Enterprise Scale.

Organization-Wide Defaults

• If allowed by your security configuration, use Public Read Only or Read/Write for the default internal access for any non-confidential data. We recommend that you set your default external access to Private to secure access for external users.
• To avoid creating parent implicit shares, configure child objects to be Controlled by Parent wherever this configuration meets security requirements.

Role Hierarchy

• Don’t create roles that are unnecessary for configuring data access. For example, don’t exactly recreate your company’s organizational chart if there are roles that have the same access requirements and can be combined.
• Minimize the number of levels in the role hierarchy. We recommend having a maximum of 10 levels.
• In Experience Cloud sites, reduce the number of partner and customer roles to one when possible.
• Move partner roles to a separate branch in your role hierarchy. Then, grant the partner users access to the partner account with a sharing rule. This configuration improves performance for realignment operations when there are account owner changes.

Public Groups

• Use public groups when multiple users in different roles have the same visibility requirements and it’s not necessary to frequently modify group membership.
• If users above the public group members don’t need access to records shared with the group, disable the Grant Access Using Hierarchies setting.
• Limit public groups to 10,000 members.
• Don’t create public groups within public groups that result in more than 5 levels of nesting.

Sharing Rules

• Periodically review sharing rules to remove redundant paths of access. For example, a sharing rule is no longer necessary because it provides access to people who already have it through the role hierarchy.
• If you have two identical sharing rules that target two different public groups, it’s better for performance to have one sharing rule that targets a single public group that includes members of both public groups.

Data Access and Ownership

• Don’t allow a single user or queue to own more than 10,000 records of an object. This condition is called ownership data skew and can cause performance issues if the owning user’s role or public groups are adjusted. To fix this issue:
  • Distribute record ownership across a greater number of users.
  • Don’t assign the user owning more than 10,000 records a role.
  • If you must assign a role to a user owning more than 10,000 records, place the user in a separate role at the top of the hierarchy so that shares aren’t materialized for superiors in the hierarchy. Then, don’t move this user from this top-level role and don’t include the user in public groups that can be used in sharing rules.
• Don’t associate more than 10,000 child records with a single parent account. This configuration, called a parent-child data skew, can cause slow performance of data updates or uploads. To fix this issue:
  • Create a pool of accounts and assign children in a round robin fashion.
  • If you have a skewed account, redistribute child objects in chunks during off-peak hours to lessen the impact of record-level lock contention. Batch Apex or the Bulk API are useful ways to reparent.
  • If possible, consider a Public Read/Write sharing model in which the parent account stays locked, but sharing calculations don’t occur.
• Don’t manually share more than 10,000 records for a given object with a user. Use a different sharing mechanism, such as sharing rules.