Salesforce Data Skew: What to Do When Prevention Is Already Too Late

You have just taken over a Salesforce org. The previous admin is gone, the documentation is limited, and the complaints are already coming in. Users are reporting slow page loads, locking errors, and sharing recalculations that seem to run forever. After digging through the org, you finally find the real issue: data skew. It has been building quietly in the background for years, and now the impact is impossible to ignore.

Most Salesforce content about data skew focuses on prevention, like designing the data model correctly from the beginning, avoiding thousands of child records under one parent, and keeping record ownership balanced. That advice is helpful, but only if you are starting from scratch. Most admins are not. This article is for the people inheriting an already messy org and trying to fix what is already there. We will look at how to identify skew in production, measure how serious it is, decide what needs attention first, and remediate it without creating even bigger problems. 

What Is Data Skew, and Why Does It Matter?

Data skew in Salesforce happens when too many records are connected to one parent record or owned by one user or queue. Instead of data being distributed evenly, it becomes heavily concentrated in one place, which creates performance issues behind the scenes. 

There are three main types of skew that admins usually run into:

• Account Data Skew: This happens when thousands of child records, like Contacts, Opportunities, or Cases, all sit under a single Account. It often leads to record locking during DML operations and can slow down or completely stop bulk data loads.
• Ownership Skew: This happens when one user or queue owns a very large number of records in an object. In private sharing models, any role, territory, or ownership change can trigger massive sharing recalculations across the org.
• Lookup Skew: This happens when a large number of records point to the same record through a lookup field instead of a master detail relationship. Similar contention and locking issues can happen here as well.

The real signs usually show up in daily operations: repeated UNABLE_TO_LOCK_ROW errors during data loads, sharing recalculations that take hours to finish, slow record pages for specific accounts, integrations that fail only for certain records, and Apex batch jobs timing out on queries that should be simple. These often look like separate problems, but many times the root cause is the same. Next, let’s look at the steps to take to fix data skew.

Step 1: Diagnose and Quantify the Skew

Before you can fix anything, you need to know exactly what you’re dealing with. You probably already know the skew exists. The goal at this stage is to quantify it well enough to prioritise the work and, if needed, make the case to leadership for why it matters.

Detecting Account Data Skew

Run the following SOQL queries in Developer Console or Workbench to identify skewed accounts:

SELECT AccountId, COUNT(Id) childCount FROM Contact GROUP BY AccountId ORDER BY childCount DESC LIMIT 20

Run the equivalent query for Opportunities, Cases, and any custom objects with a lookup to Account. Salesforce generally considers around 10,000 child records under a single parent as the point where account data skew can start creating noticeable performance problems, especially in orgs with frequent updates or heavy automation. Anything over 50,000 is critical.

Detecting Ownership Skew

SELECT OwnerId, COUNT(Id) recordCount FROM Opportunity GROUP BY OwnerId ORDER BY recordCount DESC LIMIT 20

Pay particular attention to system integration users, queue owners, and any user accounts that represent automated processes. These are the usual culprits. If a single user or queue owns more than 10,000 records in a private or controlled sharing model, you have an ownership skew issue.

Checking for Sharing Recalculation Delays

Go to Setup and open Defer Sharing Calculations. If this setting has been enabled repeatedly over time, that’s a strong sign that sharing recalculations has been a recurring headache for whoever managed the org before you. The Setup Audit Trail will show you exactly how often it’s been toggled, which tells its own story.

While you’re in Setup, check the Background Jobs section for any stuck or long-running sharing recalculation jobs. Anything that’s been running for more than a few hours needs attention.

Step 2: Not Everything Needs to Be Fixed Right Now

Once you have a clear picture of where the skew lives, resist the temptation to fix everything at once. Prioritise based on two axes: business impact and remediation risk.

• Fix first: Skew that is causing active errors in production (UNABLE_TO_LOCK_ROW in integration logs, stuck sharing recalculations, reports timing out for users). These have a clear and measurable business impact.
• Fix next: Ownership skew on users who are likely to be deactivated, have their role changed, or be added to a territory group. These are time bombs. Sharing recalculations triggered by role changes on skewed users can lock up the org for hours.
• Monitor and document: Skew that exists but isn’t causing active problems yet. Log it, set thresholds, and revisit quarterly. Not every skew situation needs surgery.

Step 3: Getting Leadership Buy-In for Invisible Work

This is the step most technical guides skip entirely, and it’s often the hardest part. Data skew remediation is expensive in time, it carries risk, and the results are invisible to end users. Your stakeholders will ask: “If it’s not broken, why are we fixing it?”

Here is how to frame it in terms that resonate:

• Translate errors into cost: If UNABLE_TO_LOCK_ROW errors are causing integration retries, quantify the volume. “Our nightly sync fails 3–4 times per week on the Acme account, each requiring a manual re-run that takes 45 minutes of engineering time.”
• Use the ‘time bomb’ framing: “If we deactivate or reassign [integration user], it will trigger a sharing recalculation on 80,000 records. Based on similar orgs, that process could lock the org for 4–6 hours during business hours.”
• Tie it to upcoming projects: If a data migration, Agentforce rollout, or new integration is on the roadmap, data skew becomes a prerequisite conversation. Frame remediation as risk reduction for those projects.

Step 4: Remediation Strategies

There is no single fix for data skew. The right approach depends on the type of skew you’re dealing with and how severe it is. Here are the most practical strategies based on what you’re likely to find in a mature org.

For Account Data Skew

• Split the parent account: If a single “Household” or “Global” account has accumulated tens of thousands of children, consider whether it should be split into regional or business-unit sub-accounts. This is a data model change and requires stakeholder sign-off, but it’s the most effective long-term fix.
• Archive historical records: In many orgs, a significant percentage of child records are old, closed, or inactive. Bulk-archiving or soft-deleting records that are no longer operationally relevant can dramatically reduce the child count without a full data model change.
• Use Big Objects for historical data: Salesforce Big Objects are designed for high-volume, historical data that needs to be retained but not actively worked on. Moving closed cases or old activity records to Big Objects removes them from the standard skew calculation.

For Ownership Skew

• Reassign records in batches: Use Data Loader or a scheduled Flow to gradually redistribute records away from overloaded owners. Do this in off-peak hours and in batches of no more than 2,000 records at a time to avoid triggering a mass sharing recalculation.
• Use Defer Sharing Calculations deliberately: If a large reassignment is unavoidable, go to Setup and use Defer Sharing Calculations to suspend sharing recalculation while the work happens, then resume it during a scheduled maintenance window. A lot of admins treat this like a workaround. But this is exactly what the feature was built for.
• Flatten role hierarchies where possible: Deep role hierarchies amplify the impact of ownership skew. If a user with 50,000 records is near the top of a long hierarchy, a role change cascades visibility calculations down through all subordinate roles. Flattening the hierarchy reduces this blast radius.

Step 5: Monitor to Prevent Regression

Remediation without monitoring just resets the clock. Once you’ve addressed the worst of the skew, put monitoring in place so you catch it early next time.

• Schedule a monthly SOQL audit: Automate the child-record-count queries via a scheduled Apex job or a Flow that writes results to a custom object, and build a dashboard to track the top 20 accounts by child count over time.
• Set threshold alerts: Use a Flow or Apex trigger to send an alert to the admin team when a single account or owner crosses a record count threshold (e.g., 8,000 child records). Catching skew at 8,000 is far easier than remediating it at 80,000.
• Document what you found and fixed: Seriously. Write it down. Future-you (and future admins) will thank you. A brief change log in your Salesforce wiki, Confluence, or even a Notes custom object entry with the date, what you found, and what you did is priceless.

Summary

Dealing with data skew in an org you didn’t build is one of the less glamorous parts of being an admin. There’s no flashy feature to demo, no announcement to make. The wins are quieter: fewer integration failures, sharing recalculations that actually finish, and a platform that stops fighting the people trying to use it.

The key is not trying to fix everything at once. Quantify what you have, prioritise what’s actually causing pain, bring stakeholders along for the invisible work, and put monitoring in place so it doesn’t quietly creep back. It’s not the most exciting project you’ll take on, but for the people depending on the org every day, it might be one of the most impactful.