The Notorious UNABLE TO LOCK ROW

A Closer Look at a Common Salesforce Error

5-minute read

Share Resource

We love Salesforce. But we hate errors.

So let's take a look at one of the most notorious errors in Salesforce and how you can troubleshoot it.

UNABLE TO LOCK ROW
A deadlock or timeout condition has been detected.

  • A deadlock involves at least two transactions that are attempting to update overlapping sets of objects. If the transaction involves a summary field, the parent objects are locked, making these transactions especially prone to deadlocks. To debug, check your code for deadlocks and correct. Deadlocks are generally not the result of an issue with Salesforce operations.
  • A timeout occurs when a transaction takes too long to complete—for example, when replacing a value in a picklist or changing a custom field definition. The timeout state is temporary. No corrective action is needed.

Now, you may wonder how such an innocent sounding error message could be so notorious. Turns out it’s really simple. This error is really a monster in disguise. Or, perhaps more accurately, a pestilence.

More data usually means more users and more complexity. More complexity usually involves more automation and business logic. More stuff running and processing data at the same time leads to more contention for resources and records. Let’s dwell on that last one for a moment.

So now what do you do? 

You wait for 30 minutes, an hour, a couple hours with no luck. Maybe it was one of those holiday celebrations in Spain where people throw tomatoes at each other all day and everyone simply needs to wash off remnants of questionable festivities the next day?

Simply put, these errors occur when a record is accessed by more than one processing stream at the same time. If some processing takes too long, the other one simply gives up after a while because it’s got better things to do. Salesforce database is multi-access. There are a lot of users and processes that can access the same part of data at the same time. The system is not allowed to contain many variations of the same stored record after all, so only one process gets to modify something at a given moment of time. Luckily, most of the processing is quick but with complexity, it becomes less so thus increasing chances of attracting the lock-row-locust.

What can we do to avoid this pestilence? Here are some tips:

  • Make sure your data model is optimized and has no Data Skews. That’s a fancy term for saying you have more than 10,000 child records for a parent record. Sound familiar? Next time you build that master-detail relationship, stop and think… How many child records can this master record really have? If the answer is “many” or “a lot” then take the time to re-evaluate and restructure.

  • Check your data for Ownership skews if you have private record sharing enabled. That one sales rep on your team that closes 10X more deals than the rest of the group combined? Or that one support engineer that crunches through cases like a swarm of rodents going through a bag of peanuts? No, we’re talking record ownership of a much higher caliber. Think 10’s of thousands or even 100’s of thousands of records. Usually this kind of situation occurs due to automation. Either a default Lead, Case, or Account owner getting assigned and forever forgotten. There are other examples.. The point is, check your data owners and don’t leave them with too much on their plate.

  • Ask support to enable granular locking for your org. This one is the last resort. If you’ve done all of the above and still have a problem, it is worth a shot.

Hopefully this takes care of your errors. Your laundry? Alas, we can't help you with that.

Useful resources:

Start getting insights today, for free