Why should a Sharing and Visibility Designer split an account instead of reviewing the sharing rules for a UNABLE_TO_LOCK_ROW error?

Question

From the Salesforce Certified Sharing And Visibility Designer exam guide:

Universal Containers has successfully implemented a large Service Cloud rollout for their national call centre 3 months ago. One of their largest customer accounts, United Automotive, has over 15,000 open cases. Agents are now having trouble opening new cases for United Automotive. When they try to create a case, the following Error message appears for them:

UNABLE_TO_LOCK_ROW

They notice that this only occurs for the United Automotive account. If they try to save the case again it will usually work, but the problem seems to be happening more and more often.

What option should the Architect recommend?

Choose one answer

• A. Review all Account sharing rules to ensure that the Customer Service team has Read/Write access to the United Automotive Account.
• B. Review the Account structure to split the United Automotive account into multiple branch accounts.
• C. Review all Case Sharing Rules and consolidate where appropriate to reduce the total number of sharing rules.
• D. Review the Customer Service Profile to ensure that they have Read/Write access to the appropriate Case and Account Fields.

The first thing I notice about this scenario is that 15k open cases for a single account seems pretty uncommon, and a huge number! In my vision this clearly indicates an issue with a product/service (or maybe negligence of the support structure). But given the possible answers, I think this might be irrelevant.

Second thing that comes to my attention is that if it happens to a single account, then of course it must be something related to that single record, and not with the account object per se. So it must be Apex or Sharing, or maybe both.

Finally, each option analysed:

• A. It is not this option because if it were a permission error we wouldn't even get the row lock error. The users would get an insufficient access error first.

• B. I don't understand how splitting the account would help here, so I ignore this option.

• C. Now this seems at least more logical. But still, I don't get how row locking might be related to the amount of sharing rules. Sharing rules take some time to be calculated when we change Organisation-Wide Defaults, depending on the amount of records for the changed object. After letting Salesforce process the change, the platform behaves normally, without delays because of the rules. I chose this option.

• D. Same thing as A.

---

Is this the kind of question in which you eliminate the wrong possibilities and are left with an option that doesn't seems right or wrong? If not, then what is the correct thought process to get to the correct answer (B)?

Answer 1

I think I have to try to tackle this one because I passed that exam this morning!

There's two layers, I think, to this sample question. One is that Salesforce is trying to see whether you're able to recognize an example of a standard scenario that they use to portray a specific issue and know what their recommended fix for that issue is. Here, they're specifically looking to see if you've read and followed Designing Record Access for Enterprise Scale, which is part of the resource guide for this exam.

In this case, the issue is parent-child data skew. This term refers to any situation where a single parent object has in excess of 10,000 child records. (Why 10,000? I don't know the exact technical rationale, but it's always Salesforce's cutoff point for identifying data skew).

One of the more or less standard recommendations from Salesforce for curing parent-child data skew is ensure that no single parent has more than 10,000 children, typically by splitting the children among multiple parent records (such as branch accounts). They're looking for you to choose (B) to show that you've read the recommended materials, understand which scenario they're presenting, and know the recommended fix.

The other layer is the technical. By consulting the Record Locking Cheat Sheet, we see that one of the situations in which inserting a child record locks the parent is that a Case insert or update always locks the parent Account. (Note this is called out as a "high" risk of lock contention).

That's ultimately where the row locking error comes from - not the data volume as such, but the volume of concurrent updates that hold that lock long enough that one or more other concurrent operations times out. Altering sharing rules might in other ways improve performance, and might in fact reduce the duration of some of the locks, but it won't fix the root cause, so ultimately this again points us to (B).

Answer 2

My thought is this question has implied processes occurring behind the scenes that are not explicitly called out. In an enterprise with this type of complexity, there would be many processes running in code, process builder, workflow, and integrations.

The row issue issue at hand is occurring because there is most likely many processes executing and trying to access the same records in the same transaction.

Segmenting the account into many branches and distributing the cases among those accounts would in many instances reduce the other process and systems that execute based on a new case being created.

Answer 3

UNABLE_TO_LOCK_ROW is nothing to do with sharing rule. Here the use case depicts about Account data skew. Salesforce recommends to split accounts so that each account cannot have more than 10,000 cases.

Let me share my real life data loading experience. I have migrated case data from old legacy system to Salesforce where a single account has more than 28,000 cases. Now to migrate data I have used bulk API to parallel upload 2 million cases and that moment I have faced UNABLE_TO_LOCK_ROW errors.

Moreover the case object didn't have any sharing rules and OWD of case was Public Read-Write.

The reason behind, each case has a look up to Parent Account and when multiple cases are getting created under same account, system will try to lock the same account and if it cannot achieve the lock in 10 secs then it will throw this error.

Answer 4

This is because if you have many records on the same account, due to roll-up summary field or any other processing salesforce also locks the parent record. Even Salesforce also recommend for less than 10K child record. Either change the owner of account to a person without role or split your account into multiple branch.