When multiple users or background processes attempt to update the same case, data conflicts can occur. To avoid inconsistent or overwritten data, Pega provides a robust case locking mechanism that governs how cases are accessed and updated.
Case locking ensures data integrity, controlled access, and safe concurrent work—making it a fundamental concept in Pega application design.
1. Introduction
Case locking in Pega prevents simultaneous conflicting updates by controlling who can edit a case at any given point.
Pega supports two locking strategies:
- Pessimistic (Exclusive) Locking – Only one user can edit a case at a time.
- Optimistic (Concurrent) Locking – Multiple users can work simultaneously, with conflict detection during save.
Locks are acquired, released, and timed out automatically, with flexible configuration options at the case type and case hierarchy levels.
2. What Is Case Locking in Pega?
Case locking is the mechanism Pega uses to maintain data consistency when concurrent access occurs.
When multiple users open the same case:
- They may receive edit access or read‑only access, depending on the locking configuration.
- Only one valid set of changes is allowed to be saved.
- Conflict resolution prevents overwrites or data corruption.
This ensures the integrity of business‑critical transactions and case information.
3. Locking Strategies in Pega
🔹 3.1 Pessimistic Locking (Default – One User at a Time)
- Only one user or process can edit a case at a time.
- Other users receive read‑only access until the lock is released.
- The lock is:
- Acquired when the case is opened.
- Released upon submit, logout, or after timeout (default: 30 minutes).
- Lock details are stored in the pr_sys_locks database table.
Use When:
Strong data consistency is required (e.g., financial transactions, compliance workflows).
🔹 3.2 Optimistic Locking (Allow Multiple Users)
- Multiple users can open and work on a case simultaneously.
- No lock is held during editing.
- At save time, Pega tries to acquire a lock briefly:
- If no conflict → save succeeds.
- If another user has saved changes → the user is prompted to refresh.
Use When:
High collaboration is needed (e.g., audits, reviews, collaborative workflows).
4. Lock Configuration & Lock Keys
Locking is configured at the case type level.
- The lock key uniquely identifies a case instance.
- Default lock key: pyID (case ID).
- Prevents accidental locking across cases.
Lock information is maintained in:
- System-Locks class
- pr_sys_locks table
Admins can view and manage locks via Admin Studio → Resources → Locks.
5. Acquiring & Releasing Locks
Automatic Locking
Pega acquires locks through OOTB rules like:
- Work-.WorkLock
- Assign-.AcquireWorkObject
Manual Locking (Advanced)
Developers can manage locks using:
- Obj-Open with locking parameters
- Page-Unlock method
- Custom activities (only when necessary)
Locks Are Released When:
- User submits the case or completes the assignment
- User logs out
- Lock timeout expires (stale locks auto‑release)
6. Locking in Parent–Child Case Hierarchies
Pega handles locking intelligently across case structures.
Default Behavior
- Locking a child case also locks the parent case
(to protect shared summary fields)
Configurable Behavior
- Allow editing the parent case even when a child is locked
- Behavior differs based on locking strategy:
- Pessimistic → Parent/child may be locked together
- Optimistic → Both can be edited concurrently, with conflict handling
7. Best Practices
✔ Use pessimistic locking for high‑risk or high‑value data
✔ Use optimistic locking for collaborative or low‑risk work
✔ Avoid custom locking unless required
✔ Tune lock timeout based on business needs
✔ Regularly monitor locks in Admin Studio
✔ Ensure background processes acquire and release locks properly
✔ Avoid long-running UI sessions that hold locks unnecessarily
–TEAM ENIGMA
