You are here:
Considerations for Making Sharing Updates
Review these considerations before making sharing changes, such as updates to organization-wide defaults, sharing rules, account ownerships, or group memberships.
Required Editions
| Available in: both Salesforce Classic and Lightning Experience |
| Available in: Enterprise, Performance, Unlimited, and Developer Editions |
General
- When you make certain updates to sharing settings or related features, such as groups, users, territories, or roles, group membership or sharing rule recalculation occurs to ensure that record access is evaluated correctly. Depending on the nature of the updates and configuration of your org, these sharing calculations can take a while to complete.
- Configuration changes that cause sharing rule recalculation include:
- Changing an organization's default sharing model
- Creating, editing, or deleting sharing rules
- Creating or transferring any records
- Updating public group members
- Creating or activating a user
- Changing users’ roles or updating the role hierarchy
- Adding or removing users from territories
- Reparenting territories
- Making changes to roles, territories, or public groups involved in sharing rules
- Configuration changes that cause group membership recalculation include:
- Changing or reparenting roles
- Adding or removing users from territories
- Updating public group members
- Updating portal account ownership if the new owner has a different role
- Configuration changes that don’t cause group membership or sharing rule recalculation include:
- Territory realignment
- Updates to sharing sets
Optimization
- Contact Salesforce Customer Support to enable the defer sharing calculations feature. You can defer sharing calculations if you must make large-scale or high-impact changes that trigger sharing recalculation, and want to suspend some automatic sharing calculations to a later time to prevent timeouts or performance issues. For more information, see Defer Sharing Calculations.
- Check to see if any user owns more than 10,000 records of an object, which can cause performance issues. We recommend that you distribute records among a larger group of users before making sharing updates. For more information, see Ownership Data Skew in the Designing Record Access for Enterprise Scale guide.
- Check to see if any accounts are associated with more than 10,000 child records, which can also cause performance issues. We recommend that you distribute records among a larger group of accounts before making sharing updates. For more information, see Parent-Child Data Skew in the Designing Record Access for Enterprise Scale guide.
- When making changes to the role hierarchy, process changes to the bottom (leaf) nodes first, then move upward to avoid duplicate processing.
- Remove redundant paths of access, such as sharing rules that provide access to people who already have it through the hierarchy.
Deferring Sharing Calculations
- Deferring sharing calculations is intended for operations like large-scale maintenance updates or org realignments that require group membership or sharing rule recalculation.
- Even if you’re making only a few configuration changes, consider deferring sharing calculations if the number of affected records or users is very large. For example, you make changes to only a few sharing rules, but for objects that have a significant volume of data. Or, you must edit a few owner-based sharing rules, but this change impacts a large number of users who own the records being shared.
- Changes that aren’t directly related to updating your sharing settings can also impact sharing recalculation and benefit from deferring sharing calculations. For example, you upload a large volume of data for one or more objects that have many existing sharing rules.
- Deferring sharing calculations doesn’t defer the recalculation of some sharing changes in order to preserve data integrity. These calculations that can't be suspended can take significant time to process based on the org's settings and data volume. Group membership locking can also still occur while sharing calculations are deferred.
- If you defer sharing rule calculations, only updates that involve sharing rules, whether directly or indirectly, are deferred, while other sharing-related changes are still processed immediately. To give a few examples, if you create sharing rules or update roles that are referenced in sharing rules, the resulting recalculations are paused. However, if you create manual shares, update teams or queues, or update roles that aren’t referenced in any sharing rules, those changes are still evaluated immediately.
- If you defer group membership calculations, membership changes involving individual users are still reflected immediately. However, membership changes related to nested groups or due to role hierarchy changes aren’t reflected until after group membership calculations are resumed and you complete a full recalculation. Any change in record access resulting from membership changes also isn’t processed until calculation is resumed and you complete a full recalculation.
- If you find that organizational changes and sharing rule updates typically complete quickly enough to be scheduled into the workday or periods of lower activity, you’re unlikely to benefit substantially from deferring sharing calculations.
- If you defer sharing calculations, you must always complete a full sharing rule recalculation after you resume group membership or sharing rule calculations. This recalculation ensures that all of your changes are reflected in your sharing rules. If you don’t do a full sharing rule recalculation, there can be issues with record access behavior.
- We recommend that you resume sharing calculations immediately after making your changes. Then, start the full sharing rule recalculation as soon as possible during a period of low activity. By resuming sharing immediately, new updates are processed immediately, meaning there are fewer changes that must be recalculated. Completing the full sharing recalculation in a timely manner then ensures that record access behaves as expected without significant lag time.
Testing
- Test making your updates, including resuming sharing recalculation if applicable, in a full copy sandbox before you make these changes in production. This test allows you to both identify any potential issues that can take time and get an estimate of how long the whole process will take in production.
- The full copy sandbox should mimic your current product environment as closely as possible. We recommend using a sandbox refreshed within the last 30 days. In addition, all major changes must be reflected in the sandbox.
Timing
- Plan for a maintenance window that’s sufficiently long to complete your changes and for the sharing recalculation to complete.
- Schedule the maintenance window for a period of low activity in your org, such as a weekend.
Did this article solve your issue?
Let us know so we can improve!
