Designing Record Access for Enterprise Scale

Designing Record Access for Enterprise Scale
Preface
Introduction
Group Membership Operations and Sharing Recalculation
Object Relationships, Bulk Loading, and Sharing Recalculation
Tools for Large-Scale Realignments
Parallel Sharing Rule Recalculation
Deferred Sharing Maintenance
Granular Locking
Takeaway: Making Realignment Smoother
Conclusion
PDF

Newer Version Available

This content describes an older version of this product. View Latest

Granular Locking

By default, the Lightning Platform platform locks the entire group membership table to protect data integrity when Salesforce makes changes to roles and groups. This locking makes it impossible to process group changes in multiple threads to increase throughput on updates. When the granular locking feature is enabled, the system employs additional logic to allow multiple updates to proceed simultaneously if there is no hierarchical or other relationship between the roles or groups involved in the updates. Administrators can adjust their maintenance processes and integration code to take advantage of this limited concurrency to process large-scale updates faster, all while still avoiding locking errors.

The key advantages of granular locking are that:
  • Groups that are in separate hierarchies are now able to be manipulated concurrently.
  • Public groups and roles that do not include territories are no longer blocked by territory operations.
  • Users can be added concurrently to territories and public groups.
  • 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.

This table lists all of the operations that can occur in parallel when granular locking is enabled. Note that certain operations, such as reparenting (moving roles within the role hierarchy), still block almost all other group updates.

Group Operation Can be Performed Concurrently with...
Role creation
  • User role change1
  • Territory reparenting
  • Territory deletion
  • Territory creation
  • Removal of user from territory
  • Addition of user to territory
  • User provisioning2
Role deletion
  • Territory reparenting
  • Territory deletion
  • Territory insertion
  • Removal of user from territory
  • Addition of user to territory
Role reparenting (includes change of portal account owner) Territory creation
Adding user to territory
  • Role deletion
  • Role insertion
  • Territory creation
  • Addition of user to territory
  • User provisioning3
Removing user from territory
  • Role deletion
  • Role insertion
  • Territory creation
  • User provisioning3
Territory reparenting
  • Role deletion
  • Role insertion
  • User provisioning3
Territory deletion
  • Role deletion
  • Role insertion
  • User provisioning3
Territory creation
  • Role reparenting
  • Role deletion
  • Role insertion
  • User role change1
  • Addition of user to territory
  • Removal of user from territory
  • User provisioning3
Provisioning internal user with an existing role
  • Role insertion
  • User role change1
  • Territory reparenting
  • Territory deletion
  • Territory creation
  • Removal of user from territory
  • Addition of user to territory
  • User provisioning3
Changing user role (User must not own any portal accounts.)
  • Role insertion
  • Territory insertion
  • User provisioning3
Provisioning first non-Community portal user under an account
  • User role change1
  • Territory reparenting
  • Territory deletion
  • Territory creation
  • Removal of user from territory
  • Addition of user to territory
  • User provisioning2
Creating second non-Community portal user under an account
  • Role insertion
  • User role change1
  • Territory reparenting
  • Territory deletion
  • Territory creation
  • Removal of user from territory
  • Addition of user to territory
  • User provisioning3
Provisioning Community user Any group membership operation
Changing portal account owner Territory creation
Changing role of a user who owns a portal account Territory creation

1 The user must not own any partner or customer portal accounts.

2 Provisioning standard user or portal user in an existing portal role

3 Provisioning any standard or portal user, including the first portal user under an account

Who’s a Good Candidate for Granular Locking?

Customers may consider using granular locking if they experience frequent and persistent locking that severely restricts their ability to manage manual and automated updates at the same time, or severely degrades the throughput of integrations or other automated group maintenance operations. Customers who only occasionally receive an error message indicating that they have encountered a group membership lock are probably not good candidates for this feature.