You can set a locking strategy for a case type to control how cases are accessed in your application. By using locking strategies, you reduce the risk of lost updates to a case by concurrently working users.
When you open a top-level case type, you can specify one of two locking strategies:
This strategy locks the case for 30 minutes or until the user submits or closes the case, whichever comes first. You can change the time period for the lockout.
Use this approach to ensure that data can be updated, and transaction integrity maintained, in both parent cases and child cases. For example, the parent case may contain properties that count or total values in the child case. Locking both parent and child cases at the same time helps to keep the counts or totals in sync.
You can override default locking at the child case level.
With this strategy, the first user to submit the case is successful. All other users who are working on the case receive notifications. They must refresh the form, review the changes made, and re-enter their own updates. With optimistic locking, you can create a condition that accepts updates from two operators at the same time. However, one user’s work will not be committed and audit trail entries for both updates may exist.
Use this approach if multiple users need to open and review cases simultaneously but do not have to update the cases.
You cannot override this setting at the child case level.
After you specify a locking strategy, it is applied to new and existing cases and inherited by all child cases of the given case type.
In most configurations, use default locking to preserve transaction integrity among cases. If you do not use default locking, the user can lose work when actions, such as bulk processing or escalation actions in a service-level agreement, are performed by other users or your application.