Fix Guides

How to Fix "Unable to Lock Row" in Salesforce

Step-by-step fix guide with AI-powered diagnosis from BuildForce.

Why Salesforce Locks Rows at All

Row-level locking prevents two concurrent transactions from silently overwriting each other's changes (a lost update / dirty write). Master-detail children escalate the lock to the parent specifically because recalculating a roll-up summary field requires the parent record to be locked for the duration of that recalculation — so any burst of child DML under one parent inherently serializes against that parent's lock.

Common Causes

• Bulk API / Data Loader jobs inserting or updating many child records under the same master-detail parent in parallel batches.
• High-frequency integrations writing to the same record from multiple concurrent API calls instead of serializing writes.
• Singleton "counter" or settings records updated in real time by every unrelated transaction in the org.
• Long-running Apex holding a lock open longer than necessary — nested DML across a hierarchy, or a callout made before commit inside the same transaction.
• Sharing recalculation competing mid-transaction with a DML operation on the same records.

How to Fix It — Step by Step

1. 1. Identify the hot record. The error and debug log usually include the record Id that failed to lock. Confirm whether it's a specific business record (a busy parent Account) or a shared 'singleton' config/counter record being hit by unrelated transactions.
2. 2. Reduce concurrency at the source for bulk loads. For Bulk API or Data Loader jobs writing many children under the same master-detail parent, lower the batch size and prefer serial processing over parallel batches when they target the same parent hierarchy.
3. 3. Serialize integration writes to the same record. If multiple integration calls can write to the same record concurrently, queue writes to that record through a single async worker instead of firing parallel API calls that all race for the same lock.
4. 4. Eliminate singleton 'counter' contention. If a trigger or Flow updates a shared settings or counter record on every transaction, every unrelated transaction in the org is now competing for that one row. Move that aggregation to an async/scheduled batch instead of updating it in real time inline with every unrelated transaction.
5. 5. Add retry-with-backoff for the residual cases. Catch DmlException, check e.getDmlType(0) == StatusCode.UNABLE_TO_LOCK_ROW, and requeue the retry via Queueable Apex (synchronous Apex can't sleep) rather than failing the whole transaction outright.
6. 6. Use FOR UPDATE for deterministic lock ordering. Where a transaction touches multiple parent records, query them with SELECT Id FROM Parent WHERE Id IN :ids ORDER BY Id FOR UPDATE so every code path acquires locks in the same order — this is what actually prevents deadlocks between two code paths, not retries alone.
7. 7. Reconsider whether the rollup needs to be real-time. If the parent's total doesn't need to be accurate to the second, move the aggregation to a nightly or hourly scheduled batch instead of a trigger-time roll-up summary field that locks the parent on every child write.

Example: Retry With Queueable

try {
    update parentRecord;
} catch (DmlException e) {
    if (e.getDmlType(0) == StatusCode.UNABLE_TO_LOCK_ROW) {
        System.enqueueJob(new RetryParentUpdateQueueable(parentRecord.Id));
    } else {
        throw e;
    }
}

This Error Is a Symptom, Not the Root Cause

A record that's hitting lock contention today is usually a structural hotspot — a master-detail parent with unusually high child fan-out, or a singleton record every automation touches — not a one-off timing accident. Run BuildForce's free health check to see how your org's overall setup compares to similar companies, then connect your org so BuildForce can flag high-fan-out relationships and singleton-record contention before the next bulk load or traffic spike turns it into a failure again.

How BuildForce Prevents This

• Continuous health checks — identify high-fan-out master-detail relationships and singleton "counter" records before they become lock-contention hotspots.
• Deployment automation — validate bulk-load and batch-size behavior against real org data before it runs in production.
• AI consultant for record-locking debugging — describe the failure and get a concrete retry and lock-ordering strategy.

FAQ