Sharing Group
A Sharing Group in Salesforce is a system-managed group that the platform creates and maintains automatically to implement record-level sharing rules, role-based sharing, territory assignments, and similar declarative sharing configurations.
Definition
A Sharing Group in Salesforce is a system-managed group that the platform creates and maintains automatically to implement record-level sharing rules, role-based sharing, territory assignments, and similar declarative sharing configurations. Sharing Groups are not directly user-facing; admins do not create them through the UI. They exist behind the scenes, populated and adjusted by the platform whenever sharing settings change, to make sharing rule evaluation efficient at query time.
Knowing that Sharing Groups exist matters in three contexts. First, performance troubleshooting: a Sharing Group recalculation triggered by a sharing rule change or a role hierarchy adjustment can lock the affected records and degrade performance for hours. Second, governor limit awareness: row-cause grants tied to Sharing Groups count against the sharing data volume that drives platform limits. Third, certification exams: Salesforce Architect exams (Sharing and Visibility, System Architect) include questions about Sharing Groups and the recalculation behavior.
How Sharing Groups work behind the scenes in the Salesforce sharing model
How Sharing Groups fit into the Salesforce sharing model
Salesforce sharing happens at the record level through ShareSObjects (AccountShare, OpportunityShare, etc.) that grant access to specific users, queues, roles, or groups. Implementing every sharing rule as direct grants on every record would be expensive, so the platform optimizes the model with Sharing Groups. Each role and each sharing rule has an underlying Sharing Group that contains the users, queues, and roles that should receive the access. The Share record on each affected record references the Sharing Group rather than individual users. When you query for who has access to a record, the platform expands the Sharing Groups dynamically. This indirection is what makes role-based and rule-based sharing scalable to millions of records and tens of thousands of users.
What triggers a Sharing Group recalculation
Sharing Group membership changes when sharing-affecting configuration changes. Common triggers: adding or removing a sharing rule, changing a role hierarchy (moving a role under a different parent), changing role assignment for a user, changing the territory hierarchy, changing public group membership, changing a queue user list, activating or deactivating a user. Each change forces the platform to recalculate which users belong to which Sharing Groups and to update the ShareSObject rows for affected records. The recalculation runs asynchronously through a Sharing Recalculation job that the platform manages. For large orgs (millions of records, thousands of users), a single sharing change can trigger hours of background recalculation. Plan structural sharing changes during low-traffic windows.
Defer Sharing Calculations during heavy changes
When making multiple sharing changes at once (a role hierarchy redesign, a sharing rule refactor, a territory restructure), running each change independently triggers a separate recalculation job for each. The platform Defer Sharing Calculations feature lets admins suspend recalculations across multiple changes and run a single combined recalculation at the end. This is the standard pattern for any sharing restructure on a large org. The feature is in Setup, Sharing Settings, with the Defer Sharing Calculations toggle. Make every change, then disable the defer and let the platform run one combined recalculation overnight. Mature orgs use this pattern routinely; without it, sharing changes can take days to settle.
Group membership operations and the GroupMember object
Sharing Groups manifest in the data model through the Group and GroupMember objects. Group records represent the Sharing Group itself (with a Type field showing whether it is a Role, RoleAndSubordinates, Territory, or a public group). GroupMember records represent the individual user-to-group membership entries. SOQL queries against these tables are how integrations and Apex code inspect sharing programmatically. The data volume on GroupMember can be substantial for large orgs; mature platforms cache frequently-queried memberships at the application layer to reduce database load. Direct manipulation of these records is not supported through the UI; the platform maintains them through the recalculation pipeline.
Sharing Group and Apex managed sharing
Apex managed sharing (declared on the ShareSObject through a custom Apex trigger or class) coexists with the declarative sharing model that uses Sharing Groups. Manual share records get a RowCause that identifies why the grant exists (Manual, Rule, Owner, Implicit, etc.). Apex managed sharing typically uses a custom RowCause to mark records the org code is responsible for, and the platform leaves those records alone during sharing recalculations. This separation lets Apex sharing survive role hierarchy or sharing rule recalculations without being overwritten. For implementations that combine declarative and Apex sharing, document which RowCauses are platform-managed (via Sharing Groups) and which are Apex-managed; mixing them up creates support nightmares.
Sharing performance, recalculation timing, and scale
Sharing Group recalculations are the most expensive operation on the platform from a database perspective. For orgs with millions of records and complex sharing rules, a full sharing recalculation can take hours to complete and locks the affected records during the operation. The platform schedules recalculations in priority order and runs them as background jobs, but high-volume orgs can see user-facing impact (slow record loads, slow sharing rule activation) during major recalculations. Salesforce provides tools to monitor recalculation progress in Setup, Background Jobs. Engage Salesforce Customer Support for any org-wide sharing redesign on a large org; they can plan the timing and provide guidance on minimizing impact during the operation.
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.
- 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.
- 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.
- 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.
- 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.
- Sharing recalculations can take hours on large orgs. A single sharing rule change made during business hours can lock affected records and degrade performance for the whole org. Plan changes during low-traffic windows.
- Defer Sharing Calculations is essential for any structural sharing change on a large org. Without it, every individual change triggers a separate recalculation; the combined runtime can take days.
- Direct manipulation of Group or GroupMember records is unsupported. The platform manages them through sharing recalculation; manual edits get overwritten on the next recalc.
- Apex managed sharing and Sharing Group-based sharing coexist through different RowCause values. Mixing them up creates support nightmares; document which RowCauses your org uses and why.
- Sharing data volume scales with Group count, GroupMember count, and Share record count. Audit quarterly through Salesforce Optimizer; bloat compounds and degrades platform performance silently.
Trust & references
Straight from the source - Salesforce's reference material on Sharing Group.
- Sharing Architecture OverviewSalesforce Help
- Defer Sharing CalculationsSalesforce Help
- Apex Managed SharingSalesforce Developer Docs
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Sharing Group?
Q2. Do admins create them?
Q3. When do they matter?
Discussion
Loading discussion…