Group Membership Locking

When updating the role hierarchy or group membership through integration or the administration console, customers might occasionally receive a “could not acquire lock” error and have to repeat the operation. This error occurs because the sharing system locks the tables holding group membership information during updates to prevent incompatible simultaneous updates or timing issues, both of which could lead to inaccurate data about users’ access rights. Typically, these locks are held only very briefly, so most customers will never see a lock conflict error. In some scenarios—such as a change in role triggering a sharing rule recalculation—locks might be held for a longer time, and conflicts might occur.

Customers who experience these locking errors are typically executing large-scale data loads or integrations with other internal systems that are making changes to role and group structure, user assignments to roles and groups, or both. When these processes are running—and an administrator tries to change a user’s role, or the customer tries to provision a new external user—one of these simultaneous operations might be unable to secure the lock it requires. The most likely time for this failure to occur is during periodic organizational realignment events, such as end-of-year or end-of-quarter processing, where many account assignments and user roles are changing.

Customers can lessen the chance of locking errors by:

Scheduling separate group maintenance processes carefully so they don’t overlap
Implementing retry logic in integrations and other automated group maintenance processes to recover from a failure to acquire a lock

You can also receive locking errors if you're updating the role hierarchy or group membership while running other deployments that also update group membership information or have Apex tests that do so. If you receive locking errors, wait for the deployment operation or Apex tests to finish.

Note

By default, granular locking is enabled, which allows some group maintenance operations 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.
- External user creation requires locks only if new external roles are being created.
- Provisioning new external 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 the operations that can occur in parallel. 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 change¹ Territory reparenting Territory deletion Territory creation Removal of user from territory Addition of user to territory User provisioning²
Role deletion	Territory reparenting Territory deletion Territory insertion Removal of user from territory Addition of user to territory
Role reparenting (includes change of site or portal account owner)	Territory creation
Adding user to territory	Role deletion Role insertion Territory creation Addition of user to territory User provisioning³
Removing user from territory	Role deletion Role insertion Territory creation User provisioning³
Territory reparenting	Role deletion Role insertion User provisioning³
Territory deletion	Role deletion Role insertion User provisioning³
Territory creation	Role reparenting Role deletion Role insertion User role change¹ Addition of user to territory Removal of user from territory User provisioning³
Provisioning internal user with an existing role	Role insertion User role change¹ Territory reparenting Territory deletion Territory creation Removal of user from territory Addition of user to territory User provisioning³
Changing user role (User must not own any site or portal accounts.)	Role insertion Territory insertion User provisioning³
Provisioning first site or portal user under an account	User role change¹ Territory reparenting Territory deletion Territory creation Removal of user from territory Addition of user to territory User provisioning²
Creating second site or portal user under an account	Role insertion User role change¹ Territory reparenting Territory deletion Territory creation Removal of user from territory Addition of user to territory User provisioning³
Provisioning high-volume Experience Cloud site user	Any group membership operation
Changing site or portal account owner	Territory creation
Changing role of a user who owns a site or portal account	Territory creation

¹ The user must not own any site or portal accounts.

² Provisioning standard user or external user in an existing portal role

³ Provisioning any standard or external user, including the first site or portal user under an account

Designing Record Access for Enterprise Scale

Group Membership Locking