Tools for Large-Scale Realignments

The most demanding maintenance activity that customers perform is a large-scale realignment of sales teams, territories, and account assignments. Whether customers do realignments annually, quarterly, or more frequently, the realignments typically involve extensive changes to an organization’s structure and updates to large amounts of data, both of which result in many changes to record access. At the same time, sales realignments are very time-sensitive.

There are several features available to help with the planning and execution of realignments, you need to contact to salesforce support to enable these.

1. Parallel Sharing Rule Recalculation- Normally, when an administrator creates, deletes, or edits a sharing rule, the recalculation required to make those changes take effect is processed synchronously. The same is also true when sharing rules are recalculated because of updates, such as a movement of roles or changes to the membership of the source group for rules. The calculation proceeds as a single job and typically completes within a few minutes. However, when data is huge, the recalculation can run longer. Also, a recalculation job can get killed if it is running when Salesforce performs a scheduled feature or patch release. User parallel sharing rule recalculation:
• If you have experienced long-running processing times or jobs that were killed during realignments, consider using parallel sharing rule recalculation
• When this feature is turned on, sharing rules are processed asynchronously and split into multiple simultaneous execution threads based on load. The processing is also more resilient; during a server restart, the jobs will be reinstated on the queue and the process will continue when the server comes back online.
2. Deferred Sharing Recalculation- Deferred means postpone or put off (an action or event) to a later time. This concept is also based on a similar meaning.
• The administrator uses the deferral feature to essentially “turn off” processing of group maintenance operations, and then makes all the desired changes to role and group membership at the same time.
• Once the changes have completed, the administrator resumes processing group maintenance, and the system performs a recalculation to make all the role and group changes take effect
• Determination criteria -There are two main criteria for determining whether deferred sharing maintenance is the right tool for your organization
•  Size and complexity of your realignment activities
• Flexibility you have to arrange a maintenance window with your customers. If you find that organizational changes and sharing rule updates typically complete quickly enough to be scheduled into the workday and weekend slack times in your use of the service, you are unlikely to benefit substantially from this feature. On the other hand, if you are able to negotiate downtime with your business customers and have been struggling to complete updates in a timely fashion, deferred sharing might be a great solution to your problem.
3. Granular locking- The literal meaning of granular is consisting of small grains or particles. The concept of granular locking is the drive from its words itself. Granular locking is used to lock the small set of records instead of locking the entire table.
   To understand Granular Locking, one has to understand GroupMembership object. GroupMembership object contains user-defined Group (Public Group) and system-defined Groups (Role Hierarchy). Just like in any object, operation performed on GroupMembership Object will lock the Record for any transaction. In general, a small change in Role Hierarchy will have complex multiple record changes in GroupMembership object.
   Problem: Parallel operation on GroupMembership object will always have locking conflict, almost always. e.g. change in Role, reparenting, user creation, community user provisioning. All these indirectly impact GroupMembership object. Also, these operations, e.g. Role Hierarchy change takes lot of time, thus the high probability of record locking conflict.
   Solution: Enable Granular Locking, to ease Role and Group related transaction if there is not conflict in the Role and the operation being performed. This will not resolve the issue entirely, but it will help prevent the LOCK error to an extent. The key advantages of granular locking are:

• Users can be added concurrently to territories and public groups.
• Public groups and roles that do not include territories are no longer blocked by territory operations.
• Groups that are in separate hierarchies are now able to be manipulated concurrently.
• User provisioning can now occur in parallel.
• Portal user creation requires locks only if new portal roles are being created.
• Provisioning new portal users in existing accounts occurs concurrently.
• A single-long running process, such as a role delete, blocks only a small subset of operations.

Reference: https://developer.salesforce.com/docs/atlas.en-us.draes.meta/draes/draes_tools.htm