A Sharing Recalculation is the process Salesforce runs to re-evaluate every record's effective access for every user, given the current sharing model. It rewrites the __Share table rows on affected objects.
When it runs:
- You change OWD (e.g., flip Account from Public Read to Private). This triggers a full recalculation on that object — every Account record is re-evaluated for every user. On large orgs this can take hours.
- You add, edit, or delete a Sharing Rule. A targeted recalc runs over records matching the rule's criteria.
- Group membership changes — adding a user to a public group, role, or queue. Salesforce recalculates anything granting access to that group.
- Role hierarchy changes — moving a user under a different manager triggers recalculation of records owned by users below the moved user.
- You manually click Recalculate in Setup -> Sharing Settings -> Recalculate, on a per-object or per-rule basis.
- Apex Managed Sharing changes — no automatic recalc; you trigger it yourself in code.
Why it's expensive: for each affected record × each potential user, the engine walks the OWD -> Hierarchy -> Sharing Rules -> Manual -> Apex layers, computes effective access, and writes/updates __Share rows. On an org with millions of records and tens of thousands of users, that is hundreds of millions of evaluations.
Practical implications for admins:
- Plan large sharing changes for off-hours. Salesforce supports deferred sharing recalc (Setup -> Defer Sharing Calculations) which lets you batch many changes and recalc once at the end — critical for maintenance windows.
- Watch the Background Jobs queue during a recalc. Some operations (mass record transfer, mass owner changes) are blocked while recalc is running.
- Test in a Full Sandbox first if your org is large. Recalc that takes 2 minutes in a small sandbox can take 8 hours in production.