1

We have some occasional row lock errors. The object in question has a master-detail relationship to Account, and another custom child relationship as well. So three objects linked together via master-detail relationships.

We've already reviewed the best practices documented here: https://help.salesforce.com/s/articleView?id=000338933&type=1

While reviewing the object structure, we've found a handful of unnecessary rollup fields. I can remove them, but then I'll need to rework several reports.

Before I remove the fields, here's my question: does removing rollup summary fields on a master record actually reduce the potential for row locks?

In the documentation, there's no mention of this approach as a way to address the problem. So perhaps because there's a master-detail relationship, the lock is going to be the same whether the rollups are present or not?

Conversely, it stands to reason that less calculation would mean a shorter lock...

Thoughts?

1 Answer 1

2

does removing rollup summary fields on a master record actually reduce the potential for row locks?

Not directly. Parent records are always locked before child records, even if there is no obvious reason why they should be (though there is a lot of "under-the-hood" stuff that explains why this rule exists), so if enough attempts are made at enough child objects of the same parent account, row locks are still possible without rollup fields.

Conversely, it stands to reason that less calculation would mean a shorter lock...

Correct. If a rollup summary causes a value to change on the parent, then the parent has to go through the entire save procedure, including validation rules, triggers, and automations like Flows and Workflows. If you can avoid these, you'll reduce the total lock time perhaps significantly.

One important thing to remember is the caution against data skew. No single parent record should have too many children, and no single user should own too many records. If you have this problem, you're going to get row lock errors with increasing frequency. In fact, avoiding data skew is more important than rollup summary fields, as those calculations can quickly become massive.

2
  • Thanks for the input. I'm pretty sure there's no data skew for the object in question, but I will double-check. This org also has almost all the objects as public read/write. So my thought is that sharing-based locking would be minimal...
    – JimG
    Commented Oct 6, 2021 at 14:45
  • @JimG Yes, but no matter what happens, there are always locks on the parents, so even in the case of public read-write, there's always a chance that a parent with heavy traffic can get this error.
    – sfdcfox
    Commented Oct 6, 2021 at 17:11

You must log in to answer this question.

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