In Salesforce the same records were processed by different automation or processes at same time. Processes like updating records through UI, getting data from APIs through integration, scheduled jobs which have large data sets, flows, triggers execute continuously . Salesforce supports this concurrency, but when salesforce encounters many transactions which are manipulating the same records, conflicts will occur. In this scenario it was very common to see UNABLE_TO_LOCK_ROW exceptions. And this error is very common in orgs with large volume data having thousands of records. While processing high volume data in short timeframes this error was quite common. We also encounter this error while batch processing , integrations, automation tasks with heavy data.
How Record Locking Works in Salesforce
Salesforce record locking is a complex process, salesforce does not just lock the records which were involved in the transaction, but it includes related records locking as well. So it ensures data relationships remain consistent during transactions.
Let’s consider a scenario where we perform DML operations like insert, update etc on a child record, salesforce temporarily locks the parent record too. So that platform can update related calculations like count, max, sum etc if necessary. If multiple transactions attempt to insert or update child records associated with the same parent, they may compete for access to that parent record.
Let’s take an example where we need to add multiple opportunities under the same account at nearly the same time. Here salesforce locks this particular account record during this transaction. So if any process tries to perform DML on this record during this period, the lock conflict can trigger the UNABLE_TO_LOCK_ROW error.
Understanding that locking can propagate to related records is essential when diagnosing concurrency issues.
Impact of Relationships and Roll-Up Calculations
Relationships between objects play an important role and have higher chances of this error. Particularly Master detail relationships have strong dependency between the records. So when child records were modified it will automatically update parent record to maintain aggregate results
Roll-up summary fields are a common example. Rollup summary fields were used to calculate totals, counts, or averages from related child records. So every time a DML operation like insert, update or delete is performed on a child record salesforce calculates sum, count, max etc and updates the parent record. During this recalculation process, the parent record is locked.
Automation and Its Effect on Lock Duration
The lock duration caused by processes on a record will extend more as the number of automation layers increase. For example when we run a process like creating a record all the automation processes like Apex triggers, flows, work flow rules etc might get fired. Although these automation processes operate efficiently under normal conditions, the execution time can increase significantly when complex logic is involved and as long as the transaction remains active, the associated records remain locked. Which causes an increase in lock duration which in return increases the chance of getting this error as the records are being locked.
Lock Conflicts in Batch and Integration Processing
- Another main reason for this error is Batch Processes. Batch apex is mainly focussed on dealing with large datasets asynchronously, which also run parallely. When different batches update records that share common relationships, they may attempt to lock the same records.
- For example, two batch jobs might process different groups of contacts but update their parent accounts during execution. Even though the contacts themselves are different, both batches interact with the same accounts. When both jobs attempt to update the same account simultaneously, one transaction may fail with a locking error.
- External integrations can produce similar issues. External APIs systems insert or update records in bulk, and if multiple integration requests target the same parent records, lock conflicts can occur frequently. High-throughput integration environments therefore require careful architectural planning to avoid concurrency problems.
Identifying the Source of Locking Errors
- Finding and solving locking errors needs analysis of context in which they occur. For UNABLE_TO_LOCK_ROW error debug logs contain exception messages, and DML operation that has failed. Reviewing those log entries helps to find which objects were involved in error and processes were executed during that transaction.
- Monitoring asynchronous jobs also provides useful information. If multiple asynchronous apex like batch jobs or queueable jobs run at the same time, then developers should check whether the processes were run on the same data.
Architectural Approaches to Prevent Locking Conflicts
Improving System architecture is the best option compared to applying quick fixes for this error. As we discussed earlier, large transactions have locks for longer periods,which has a higher chance of conflicts. So processing records into smaller batches releases locks sooner than bulk processing.
Another effective way is to minimizing or remove unnecessary updates to records. Moving certain processes to scheduled jobs, scheduled paths, or other async processes can significantly reduce the workload by distribution and reduce simultaneous access.
Building Lock-Resilient Salesforce Systems
Building a retry mechanism was the best system to overcome this issue if the error continues even after careful planning. Using a retry mechanism if a transaction has failed because of lock on records the application will wait for a while and attempt the process to run again. Since the locking period of record is short, the retry attempt will mostly succeed.
By dividing records into smaller batches, optimizing logic, using async apex, using retry mechanism, and chaining the processes to run after the other can significantly reduce the occurrence of locking conflicts. When these practices are applied effectively, Salesforce applications remain stable even under heavy load.
