Skip to main content
This content is now archived and is no longer updated. Progress is not calculated. Pega Cloud instances are disabled, and badges are no longer awarded. Click here to continue your progress in the latest version.

Case locking

Concurrent access and overwrite risk

When two or more actions attempt to update a case, the last-performed action may overwrite data written by a previous action. Overwrites can lead to the corruption or loss of data, delaying case processing, and potentially leading to the incorrect resolution of the case. If an application supports concurrent users, an appropriate case locking strategy is essential to ensuring data integrity.

To avoid data corruption or loss due to overwrites, configure an appropriate locking strategy for each case type. Pega Platform™ supports two strategies to balance the need for user access with the need for data protection: pessimistic locking and optimistic locking.


Pessimistic locking

With a pessimistic locking strategy, an application applies an exclusive lock when opening an item, such as a case. A user or the system that opens the object gains exclusive access to the object until the application releases the lock. While the item remains locked, other users cannot edit the item.

For example, an underwriter reviews an open life insurance claim to determine the amount of benefit for which a claimant is eligible. A complex claim may require extensive calculations and referrals to external parties as the underwriter collects data and updates the case, and any other changes may override claim amounts and calculate an incorrect payout to the claimant. In this case, apply a pessimistic locking strategy to prevent other users from overwriting data when the underwriter updates the claim to prevent other users from changing the payout amount.

In the following image, click the + icons to see an example of pessimistic locking.

Optimistic locking

With an optimistic locking strategy, an application does not apply an exclusive lock when opening an item. Instead, any user — or the system itself — can open and edit the item at any time. When the item changes, the application checks whether the item has changed before committing any changes.

For example, a manager must review the most recent information for a specific service request case. The manager does not need to update any information, and a case worker may need to update the case at the same time. In this case, apply an optimistic locking strategy so that the manager avoids locking the case, preventing a case worker from completing an assignment to advance the case toward resolution.

In the following image, click the + icons to see an example of optimistic locking.

Case locking with Pega Platform

You configure case locking from the Settings tab of the Case Designer in either App Studio or Dev Studio. Pega Platform provides two locking options for case locking.

Note: Selecting the appropriate locking strategy for a case type requires a thorough knowledge of the process and the personas involved. Consult with project stakeholders to identify any business needs that affect the choice of locking strategy.
Case locking options

Select Allow one user to apply a pessimistic locking strategy. When a user opens the case, Pega Platform locks the case to prevent other users from applying any changes. When you select Allow one user, you can set a time-out value for the lock. After the time-out period lapses, another user can open and update the case. The default time-out period is 30 minutes.

Note: By default, Pega Platform selects the Allow one user option when creating a case type, which ensures data integrity during case actions.

Select Allow multiple users to apply an optimistic locking strategy. When you select Allow multiple users, Pega Platform checks for changes to the case when a user attempts to save their updates. If the case has changed, Pega Platform prompts the user to either reload the case and reapply any changes or close the case without saving their changes.

Caution: When you update a case with an automated action, such as an activity, check for a lock as part of the operation, and include steps to address a locked case. In addition, lock a case when using the Obj-Open or Obj-Open-By-Handle methods, and remember to release the lock upon completing the action. For more information on locking cases from an activity, see the help topics Object locking and Commit method.

Case locking and child cases

A complex business process that involves multiple parties or multiple types of work may use one or more child cases to model part of the business process. For instance, an auto insurance claim case type may use child cases to process claims of damages to vehicles, property, and personal injury. Specialized case workers can process each child case in parallel to reduce processing time for the parent claim. 

If a case includes one or more child cases, the child cases inherit the locking strategy from the parent case. Pega Platform identifies the locking strategy in effect for the child case on the Settings tab.

By default, if Allow one user is selected for the parent case, Pega Platform locks the parent case whenever a user opens a child case. To override this behavior and allow a second user to update the parent case while the child case is open, select the Allow other users to access parent case when the child case is opened check box.

Case locking options for a child case
Caution: If you configure a child case to override the locking strategy of the parent case, configure the time-out value of the child case to be less than the time-out value of the parent.

If Allow many users is selected for the parent case, Pega Platform prohibits case locking configuration on any child case.

Check your knowledge with the following interaction.

This Topic is available in the following Module:

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice