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 a 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 portal 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

• Using the granular locking feature to allow some group maintenance operations to proceed simultaneously