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:


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)?

  • 1
    I believe you are looking for answers related to Account Data Skew so I believe B would be correct: "Every time a record is inserted or updated, Salesforce must lock the target records that are selected for each lookup field; this practice ensures that, when when the data is committed to the database, its integrity is maintained." - developer.salesforce.com/blogs/engineering/2013/01/…
    – Eric
    Commented Jul 4, 2018 at 3:16

4 Answers 4


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).

  • 2
    My guess for "why 10,000" would be that it's an empirical average. It'd have to take into account the platform's capacity to distribute row locking among transactions fairly without making them time out. If 10 transactions launched 0.1ms apart each lock the same Account, I think Salesforce can manage to prioritize them so they lock in order and all finish within a few seconds. But as that number grows you start to reach timeout territory. Pile on top of that the likelihood that one org has X records active at once and the typical complexity of automations in large orgs.
    – Charles T
    Commented Jul 4, 2018 at 3:33
  • 1
    The implicit parent row-lock is exactly the problem at hand. The larger the number of children, the more likely it'll occur, and 15k records suggests that this account is heavily used, so splitting the account into a hierarchy is definitely the ideal solution.
    – sfdcfox
    Commented Jul 4, 2018 at 6:00
  • Thank you for your comments! And David, congratulations on passing this exam! I hope to pass it too, when I take it in a couple of months. Plenty of time to study those docs you provided. 😉 Commented Jul 4, 2018 at 12:04

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.

  • That was one of my initial thoughts as well, but the question does not mention how many processes are running on the system (or even if there are any custom declarative logic). This makes me think that this isn't the correct path to get to the answer. Commented Jul 4, 2018 at 3:02

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.


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.

  • Can you please link the documentation which specifies this? And how am I supposed to know that there's a roll-up on the Account, since it is not mentioned on the question? Commented Jul 4, 2018 at 3:03
  • 1
    Removing the owner from the role hierarchy is the solution to a different data skew issue that won't solve this one.
    – David Reed
    Commented Jul 4, 2018 at 3:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .