Print this page

How to avoid getting lock errors in your Organization

Knowledge Article Number 000005038

What are group membership "org" locks?

The Sharing capabilities of Salesforce give administrators great flexibility in modeling their organization and sharing information between different groups of people. Administrators can define a role hierarchy, create public groups, establish queues for work teams, and organize sales operations with territory management. Accurately maintaining the membership of all these groups is crucial, as mistakes could lead to exposure of sensitive information to the wrong people. Accordingly, Salesforce uses various kinds of database locks to ensure that updates to group membership don’t interfere with each other and introduce incorrect data in the sharing system.

While these locks protect the integrity of customers’ security configuration, they can also generate error messages for some large organizations when trying to perform multiple updates at the same time. These errors, called "lock errors," indicate that an update was "locked out" (that is, not allowed to proceed) because a previous update had already locked the table that maintains group membership, and was still running. For customers with a lot of data and a very large number of roles and public groups, the probability of obtaining these locks is greater, and can become a serious performance issue for their maintenance processes. For example, customers may find that their administrators cannot perform manual operations like creating users while an automated process that changes group membership is running. Or they may wish to use multi-threading in integration with other systems, but discover that they encounter so many lock errors that their throughput is greatly reduced.


What is the granular locking feature?

Granular locking can help customers who experience these locking issues. Without this feature, our code locks the entire table that keeps track of people’s membership in various groups. This means that any two administrative operations that change roles, public groups, or territories will conflict if they happen simultaneously. With granular locking, the code first analyses each operation and locks only the portions of the table touched by each. This makes it much less likely that any two group membership operations will conflict, and so customers who are using this feature will experience many fewer locks. In most cases, customers will find that with granular locking they can perform manual administration while automated update processes are running, and introduce some degree of multi-threading into integration code and other automated processes.

How can I tell if I should use granular locking?

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.  Customers should consider using this feature only if they experience frequent and persistent locking that severely restricts their ability to manage both manual and automated updates at the same time, or severely degrades the throughput of integrations or other automated group maintenance operations.

Note: More detailed information on these topics can be found in our documentation about designing records access

promote demote