The salesforce unable to lock row error shows up when two processes try to update the same record, or its parent, at the same time. One transaction wins the lock, the other gets rejected, and your deployment rolls back without touching most of what it was actually meant to change. It feels random. It almost never is.
Most teams treat this error as bad luck and hit retry. That's the wrong instinct. A deployment that fails on row locking once will usually fail again under the same conditions, because the thing causing the contention, a trigger, a bulk update, a sharing recalculation, hasn't gone anywhere. Retrying just delays the conversation you need to have about why your org is fighting itself during releases.
What actually gets locked
Salesforce locks records during a DML operation to keep data consistent. If a trigger on Account updates a field, the Account row locks for the duration of that transaction. Any other process trying to touch that same Account, including a parent record lock cascading down from a related Opportunity update, has to wait. If it waits past the lock timeout, it throws UNABLE_TO_LOCK_ROW and dies.
Deployments are prime territory for this because metadata changes often trigger data-touching side effects. Activating a new validation rule, deploying a Flow that fires on record save, or running a post-deploy data fix script can all generate DML against records that a different automated process, a scheduled batch job, an integration sync, is hitting at the same moment.
The parent-child piece catches people off guard. Updating a child record can lock the parent if sharing rules or roll-up calculations touch it. A bulk update to 200 Contacts under one Account can lock that Account long enough to block an unrelated deployment step trying to update the same Account record for a data fix.
Why it clusters around release windows
Lock errors rarely show up evenly across the week. They spike during deployments, month-end batch runs, and whenever someone kicks off a full data load right after a release. That clustering is the tell.
Deployments often include post-deploy Apex, data migration scripts, or Flow activations that run as soon as metadata lands. If your release window overlaps with a scheduled Apex job, a middleware sync from NetSuite or an ERP, or a marketing automation tool pushing lead updates, you've created a collision by scheduling, not by code quality.
Sharing recalculation makes this worse. Changing a role hierarchy, a sharing rule, or a public group during a release forces Salesforce to recalculate access across potentially millions of records. That recalculation holds locks. Any deployment step or integration job that tries to write to an affected object during the recalculation window gets queued or rejected.
Common triggers worth checking first
Before assuming the error is a fluke, check these in order. They account for the large majority of cases we see in client orgs.
- Recursive triggers that re-enter the same object multiple times in one transaction, extending lock duration
- Roll-up summary fields or declarative rollups recalculating on a parent while a child batch update is running
- Sharing rule or OWD changes kicked off during or right before a deployment window
- Scheduled Apex or Batch Apex jobs overlapping with deployment post-install scripts
- Integration middleware pushing high-volume updates on a fixed schedule that happens to match your release cadence
- Large data loads using Bulk API in serial mode against objects with heavy trigger logic
Debug logs will show the lock contention but won't always tell you who else was in the transaction. Event Monitoring or the Lightning Platform's Apex execution logs are more useful here, since they let you line up timestamps across processes instead of guessing from a single stack trace.
Fixing it at the deployment level
The first fix is sequencing, not code. Schedule deployments outside the windows when batch jobs, integrations, or scheduled Flows are active. This sounds obvious and almost nobody does it consistently, especially in orgs running multiple release trains across Sales Cloud and Service Cloud teams.
Second, break large post-deploy data updates into smaller batches with explicit ordering. Updating 50,000 records in one DML statement inside a deployment script is asking for trouble if any other process touches the same object family. Chunking the update and adding short delays between batches gives other transactions room to finish and release their locks.
Third, be deliberate about FOR UPDATE in Apex. It's useful for preventing race conditions on records your own code is about to modify, but overusing it, or locking a broader record set than necessary, creates exactly the contention you're trying to avoid. Lock only what you're actually changing.
Fourth, separate sharing recalculation from functional deployments. If a release includes an OWD or sharing rule change, run it as its own deployment in its own window, not bundled with twelve other metadata changes and a data fix script. Recalculation can take minutes or hours depending on data volume, and bundling it with unrelated changes makes root-causing a lock failure much harder later.
Where sandbox testing actually helps
You can't fully predict lock contention in a sandbox that doesn't resemble production in record volume or automation load. A partial copy sandbox with a handful of test records won't trigger the same roll-up recalculation timing or batch overlap that production sees. This is one of the quieter reasons teams get blindsided by UNABLE_TO_LOCK_ROW the first time a deployment hits a full production dataset.
This is where tools like SproutEzee earn their keep. Building production-like data volume and relationship density in a sandbox before a release lets you reproduce lock contention under realistic conditions, rather than discovering it for the first time during a live deployment window with customers watching the case queue.
On the deployment side, DeployEzee gives teams control over sequencing, so post-install scripts, Flow activations, and sharing changes can run in a defined order rather than firing all at once. Ordering deployment steps deliberately, instead of letting a single large package deploy everything simultaneously, removes a meaningful chunk of the lock contention that shows up in big-bang releases.
What to do when it happens anyway
Lock errors will still occur occasionally even in well-sequenced orgs, because some contention comes from systems outside your control, like a third-party integration on its own schedule. When it happens, resist the urge to just retry and move on.
Check the timestamp against scheduled jobs, integration logs, and any other deployment activity running in parallel. Nine times out of ten the overlapping process is identifiable and schedulable around. Document it, because the next deployment that touches the same object family will hit the same wall if nothing changes.
If the pattern keeps recurring on the same object, it's worth asking whether the automation on that object has gotten too heavy. Orgs that have layered trigger logic, Flow automation, and validation rules onto the same object over several years often carry lock risk that has nothing to do with any single deployment and everything to do with accumulated complexity nobody has gone back to clean up.
Frequently Asked Questions
What does UNABLE_TO_LOCK_ROW mean in Salesforce?
It means two transactions tried to update the same record, or a related parent record, at the same time and one of them had to be rejected. Salesforce locks a row during any DML operation to keep data consistent, and a competing transaction that cannot acquire the lock within the timeout window throws this error. It is a concurrency error, not a data corruption error, so the rejected transaction simply did not commit.
Why does this error show up more during deployments?
Deployments often trigger post-install Apex, Flow activations, or sharing recalculations that generate DML against records other processes are also touching. If a scheduled batch job, an integration sync, or a bulk data load runs at the same time as the deployment, the two compete for locks on the same object. The error clusters around release windows because that is when the most automation fires at once.
Can scheduling the deployment window actually prevent it?
Yes, in most cases. Checking what scheduled Apex, batch jobs, and integration syncs run on a given object before scheduling a deployment removes a large share of the contention. It will not eliminate every instance, since some triggers come from external systems, but it addresses the most common and most predictable cause.
Is UNABLE_TO_LOCK_ROW related to sharing rule changes?
Often, yes. Changing ownership-based sharing, role hierarchies, or public groups forces Salesforce to recalculate record access, which can hold locks on affected records for an extended period. Any deployment step or integration trying to write to those records during the recalculation can get queued or rejected, which is why sharing changes deserve their own deployment window separate from functional metadata changes.
How do you debug which process is causing the lock?
Start with debug logs from the failed transaction to identify the object and record involved, then cross-reference the timestamp against scheduled Apex jobs, batch jobs, and integration activity logs running at the same time. Event Monitoring gives a broader view across concurrent transactions than a single debug log. In most cases the competing process is identifiable once you line up the timing rather than looking at the failed transaction in isolation.