Data Skew in Salesforce – Why it Matters

Share this article...

As a golden rule within Salesforce, you should not have more than 10,000 records owned by a single user, with look-ups to one record, or related to the same Account record. This is known as Data Skew.

Salesforce Data Skew types include: Account Data Skew, Lookup Data Skew, and Ownership Data Skew. In this guide, we’ll dive into the different types of Data Skew in Salesforce, and how to avoid Data Skew from happening.

Account Data Skew

Let’s start with Account data skew. The Account object is special in the sense that it has unique relationships with other objects such as Contacts and Opportunities.

Whenever a related ‘child’ record such as an Opportunity is being updated, a temporary hold or ‘lock’ is put in place on the parent record. This ensures data integrity and allows Salesforce to perform other updates in the background, such as running validation rules and automation. In normal circumstances, you wouldn’t even notice this, but if you are updating a large number of records with the same parent, this temporary lock can cause updates to fail.

Next up, let’s imagine you have a sharing model where access to Contacts is Private and you have a number of sharing rules to ensure that sales users only see the Contacts they need to. If you have a large number of Contacts (> 10,000) related to the same Account and you change the sharing rules, this forces a recalculation which could cause performance issues for your users.

Lookup Data Skew

Lookup data skew is similar to Account data skew, whereby it is caused by many child records looking up to the same parent record.

To give this context, let’s think about a sales company that has sales targets for different regions and has created a custom object to track these. They have automation running in the background to automatically relate each Opportunity to the correct target and have ambitious plans to grow in the near future.

What would happen if they started to have > 10,000 records related to the same sales target record?

They would start to experience some of the symptoms of Lookup data skew, where records would be temporarily ‘locked’ during each update and as such, system performance could be impacted or large update operations could fail.

Ownership Data Skew

Lastly but not least let’s touch on ownership data skew.

Within Salesforce you can set up a role hierarchy to reflect that of your organisation and share records with managers or ensure that cases are only visible to the customer service team.

If you had a super-efficient customer service team that resolved cases quickly, over time they would, in turn, own a large number of records.

If you were to adjust the role hierarchy, Salesforce would need to recalculate who has access to each record. This again could cause issues when dealing with a large number of records.

Reduce the Impact of Data Skew

With data skew there are some simple steps you can take to reduce the impact on performance:

  • Avoid records being owned by generic ‘system’ users. If this is necessary, don’t assign these users a role or give them a role at the top of the hierarchy.
  • Use ‘round robin’ logic to distribute records between different holding records, if holding records are absolutely necessary.
  • Regularly remove old records from the system to reduce the number of records being held.
  • Consider an open sharing model using the defaults of Public Read/Write to reduce the impact of recalculating sharing rules.
  • Limit automations as much as possible and remove unnecessary code to try to improve the time taken for a record to be saved.
  • If you are using a custom object to store sales targets, as per my example, consider if you could use a picklist field instead, to cut back on the number of records and relationships in the system.

Summary

When planning implementation or changing the design of a current Salesforce org, be sure to consider Account data skew, Lookup data skew and Ownership data skew, to try to avoid them as much as possible.

Ultimately, Salesforce is not a data warehouse designed to store and hold millions of records. Therefore, if you are dealing with large volumes of data, refer to my top tips to try to lessen the impact.

For further information be sure to check out the guides below.

References

3 thoughts on “Data Skew in Salesforce – Why it Matters

  1. In the ownership data skew section there is A photo of the sharing hierarchy. How does one access the specific feature inside of salesforce? I have never seen this lightning Model before.

  2. Some of the suggestions above, though they would work, are really not the route to address this issue. Setting Public Read/Write on objects to avoid data skew through sharing should be a last resort. That prevents any form of security. Public records should be because it is truly open to all, not because Skew is occuring. Limiting automation, just isn’t practical. Automation is in place because it is needed. You can certainly streamline where you have a controlling flow, or a trigger framework to manage. But just reducing because it is taking too long to store? Finally Custom objects are put into place to hold SETS of data that are then linked back to a parent object. You move to a Related object when there is a 1 to many, or even a Many to Many through a Junction. So Don’t eliminate this correct relationship because of Skew. Again look at other ways to minimize or address, don’t mess up your data model to avoid relationship skew.

Add Comment