Yuvraj Kasture, founder of Digiteins - an enterprise content operations company.
You go to edit a page. The CMS stops you politely: this item is locked by jsmith. You check. jsmith left the company in 2022.
If you have run an enterprise CMS for any length of time, you have met a ghost like this. A lock with no owner, holding a piece of content hostage, left behind by someone who is no longer here. It is a small thing. It is also more revealing than it looks.
How the ghost gets there
Nobody creates an orphaned lock on purpose. It happens in the most ordinary way possible.
An author opens an item to edit it. Then life intervenes. They get pulled into a meeting, they go to lunch, they finish for the day, or, in jsmith's case, they leave the organisation entirely. The item they opened was never closed. The lock they placed was never released.
And because the lock is invisible until someone else needs that exact item, nobody notices. The content sits there, quietly locked, sometimes for years. The person is long gone. The lock remains.
Every orphaned lock is a small record of a moment when someone opened something and got interrupted.
The quick fix that is not really a fix
When you finally hit the ghost, the immediate solution is simple. An administrator unlocks the item manually, and you get on with your work.
Problem solved. For that one item.
The trouble is that this is treating a symptom. Next week, a different author will open a different item, get interrupted in the same ordinary way, and leave behind another lock. Unlock them one at a time and you are not fixing anything. You are tidying up after a process that keeps generating mess.
The real question is not “how do I clear this lock?” It is “why do we keep accumulating them, and what would stop that?”
The actual fix
Orphaned locks are not a technical problem. They are an operational one. Which means the fix is operational too, a handful of small disciplines that, together, keep the ghosts from ever settling in.
Auto-unlock after inactivity. Most platforms let you configure locks to expire after a set period with no activity. This alone clears the majority of stale locks before anyone notices them. The lock does its job while someone is actively working, then releases itself when they are not.
Make it part of offboarding. When someone leaves the organisation, unlocking their items should be a step in the exit process, the same way you revoke their system access. A simple script can release everything they had locked in seconds. jsmith should never have been able to hold content two years after departure, and with an offboarding step, they would not.
Give locks visibility. A regular, gentle reminder that lists each author's currently locked items does something quietly useful: it lets people tidy up after themselves. Most authors do not even realise they have left something locked. Show them, and they will clear it.
Allow override, with a record. Designated users should be able to unlock others' items when needed, with every action logged. The logging matters. It means nothing happens silently, and there is always a trail of who unlocked what and why.
Why a small thing is worth this much attention
You might reasonably ask whether orphaned locks deserve a whole article. A stuck lock here and there is hardly a crisis.
But that is exactly why they are worth talking about. Locks exist for a good reason: they stop two people overwriting each other's work. That is genuinely useful. The problem is not the feature. The problem is what happens when nobody is responsible for the feature's after-effects.
An orphaned lock is a small example of a much larger pattern in enterprise content operations. A capability is put in place for a good reason. It works. And then, slowly, its side effects accumulate because no one owns the ongoing housekeeping. The lock outlives its purpose. The content drifts. The small maintenance nobody scheduled becomes the friction everyone feels.
A healthy CMS instance has almost no stale locks. That does not happen because the platform is better. It happens because someone is paying attention, because the small, unglamorous housekeeping is actually being done.
That, in the end, is the difference between a platform that runs well and one that merely runs. Not the technology. The care taken with the small things, day after day, long after everyone has moved on to the next big project.
The ghosts only settle where nobody is watching.