When a record gets locked, administrators can't clear the lock themselves. Every stuck record means raising a support request and waiting. That's slow for the user who's blocked, it's avoidable load on the support team, and for something time-sensitive it stops work outright.
The underlying cause is worth separating from the symptom. Locks that clear themselves properly shouldn't need clearing at all — if admins are regularly raising tickets for this, either locks are being left behind by sessions that ended badly, or the timeout is too generous, or both. The self-service tool is the right fix, but it may not be the only one.
Objective
Give administrators a safe, audited way to see locked records and release locks without going through support.
In scope
An admin-accessible view of currently locked records
Ability to release a lock from that view
Visibility of who holds the lock and since when
Audit trail on every release
Out of scope
Changing the locking mechanism itself
Letting non-admin users clear locks, including their own
Functional requirements
Confirm what kind of lock this is. Before building anything, engineering confirms what's actually being cleared: an edit lock held while a user has a record open, a stale lock left behind by a dropped session, a batch or process lock, or something else. Different lock types carry different risks when force-released, and the answer changes how much protection the screen needs.
Locked records view. Admins get a screen listing currently locked records. For each one: the record and its type, the user holding the lock, when the lock was taken, and how long it's been held. Filterable and searchable, so an admin chasing a specific record can find it rather than scrolling.
Release. Admin selects one or more locks and releases them. The record returns to normal editable state.
Guard against data loss. This is the part that needs care. If the lock holder genuinely still has the record open and unsaved changes in front of them, releasing the lock underneath them can lose their work or let two people save over each other. Options, in rough order of effort:
Show lock age prominently and let the admin judge
Warn harder on locks younger than some threshold, on the assumption those sessions may still be live
Detect whether the holding session is actually still active and treat live sessions differently from dead ones
Notify the lock holder when their lock is released
Worth deciding how much of this we want before build, rather than adding it after the first incident.
Stale locks. If the diagnosis shows most of these are abandoned locks from dropped sessions, an automatic timeout that clears them without admin involvement would remove much of the need for the screen. Not a substitute for it, but likely the bigger win.
Permissions. Restricted to administrators. Not delegable to standard users.
Validation and audit
Standard Catch-e confirmation prompt before release, naming the record and the lock holder
Every release audited: which record, which lock, who held it, who released it, when, and how long the lock had been held
Audit retained and reportable, so we can see whether the underlying lock problem is improving
Acceptance criteria
An administrator can find a locked record and see who holds the lock and for how long
An administrator can release the lock without raising a support request
The record is immediately editable afterwards
Every release is audited
Non-admin users can't release locks
Releasing a lock doesn't corrupt the record or silently discard another user's saved work