Managing Sharing Groups indirectly through sharing changes

Direct configuration of Sharing Groups is not a thing; the platform manages them automatically. The configuration work for admins is around the sharing settings that create and update them: sharing rules, role hierarchy, territories, queues, public groups. The four-step routine covers: design the sharing model with Sharing Group impact in mind, defer sharing calculations during heavy changes, monitor recalculation jobs, and audit sharing performance over time. Each step protects platform performance from the consequences of unmanaged sharing changes.

1. 1
   Design the sharing model with Sharing Group impact in mind

   When designing a sharing model, think about how many Sharing Groups the configuration will generate. Each role generates Role and RoleAndSubordinates Sharing Groups. Each sharing rule generates an underlying Sharing Group. Each public group is a Sharing Group. For a 100-role hierarchy with 50 sharing rules and 100 public groups, the platform maintains roughly 300+ Sharing Groups. Each group has membership recalculated on every affecting change. Simpler sharing models scale better; complex hierarchies plus many sharing rules plus many public groups produce slow recalculations and degrade everyday performance. Aim for the simplest model that meets the requirements.

2. 2
   Defer sharing calculations during structural changes

   For any sharing change that touches more than a handful of records or affects more than a small role subtree, enable Defer Sharing Calculations in Setup before starting. Make all the planned changes (add or remove sharing rules, adjust role hierarchy, modify territories) without triggering recalculations after each one. After the last change, disable the defer and let the platform run one combined recalculation. The combined run is typically faster than multiple separate runs and produces less user-facing impact. Always enable defer for any sharing project; skipping it on a large org has been the cause of multiple all-day outages.

3. 3
   Monitor sharing recalculation jobs

   From Setup, open Background Jobs (or Apex Jobs for Apex-driven sharing). Sharing recalculations show up as Sharing Recalculation jobs with progress indicators. Watch the progress during and after any sharing change. Jobs that fail or stall need engineering attention; do not assume they will retry automatically. Build a dashboard alert that flags Sharing Recalculation jobs running longer than the org SLA. The alert routes to the admin team during business hours and to on-call during off-hours. For high-volume orgs, treat Sharing Recalculation as a tier-1 production job that deserves real monitoring.

4. 4
   Audit sharing performance over time

   Quarterly, review the sharing data volume on the org. Salesforce Optimizer surfaces the count of share records per object, which translates directly to Sharing Group impact. Identify objects with bloated sharing tables (more than 10x the record count) and investigate; the bloat usually comes from redundant sharing rules or over-granular public groups. Consider sharing model simplifications: replacing role hierarchy sharing with explicit sharing rules, replacing complex public group memberships with simpler ones, archiving stale Apex shares. Document each sharing change in the org sharing runbook for audit. Without active governance, sharing complexity compounds and platform performance degrades silently.