Sharing Model
The Sharing Model in Salesforce is the complete record-level access architecture that determines which users can see and modify which records across the org.
Definition
The Sharing Model in Salesforce is the complete record-level access architecture that determines which users can see and modify which records across the org. It is not a single feature but a layered system combining Organization-Wide Defaults (OWD), Role Hierarchy, Sharing Rules, Manual Sharing, Apex Managed Sharing, Account Teams, Opportunity Teams, Case Teams, and territory-based sharing. Each layer adds permissions on top of the layers below; permissions are additive, not subtractive, with limited exceptions.
The sharing model works alongside but separately from profile-level permissions. Profiles say "this user can read Accounts in general"; the sharing model says "this user can read this specific Account record." Both must permit the access for a user to see a record. Designing the sharing model is one of the most consequential decisions in a Salesforce implementation because it shapes who can do what across every object in the org. Mature orgs invest significant architectural effort in the sharing design and audit it regularly as the business evolves.
The layered sharing architecture
Organization-Wide Defaults: the baseline
Every object in Salesforce has an Organization-Wide Default (OWD) setting that establishes the baseline sharing for that object. The standard values are Private (only the owner sees the record), Public Read Only (everyone with object access can read), Public Read/Write (everyone can read and edit), Public Read/Write/Transfer (Lead/Case only), or Controlled by Parent (for detail records on master-detail relationships). The OWD is the floor; every other sharing mechanism opens up access from that floor. Setting the right OWD is the architectural starting point: too open and the rest of the sharing model is meaningless, too restrictive and the model becomes a complexity burden as you layer rules on top.
Role Hierarchy: vertical sharing
The Role Hierarchy gives upward visibility through the org chart. If a sales rep owns a record, the rep's manager, the manager's manager, and so on up the hierarchy all see the record automatically. This is configured at the object level: each object's sharing settings page has a Grant Access Using Hierarchies toggle. Most objects respect the hierarchy; specific objects (custom objects in particular) can opt out. The Role Hierarchy is the most fundamental upward-sharing layer and matches how most enterprises operate: leadership sees what their teams own. Misaligned hierarchies (the role hierarchy does not match the reporting structure) cause endless confusion in sharing investigations.
Sharing Rules: criteria-based and ownership-based
Sharing Rules open up access from the OWD baseline based on either record ownership (records owned by users in Role A are shared with users in Role B) or record criteria (records matching some field condition are shared with a specific group). They support sharing with Roles, Roles and Subordinates, Public Groups, Queues, or Partner roles. Sharing Rules are the workhorse of most sharing models, handling the bulk of cross-team visibility requirements. Each rule recalculates when the underlying ownership or criteria change, which can trigger heavy sharing-recalculation jobs in large orgs.
Manual Sharing and Apex Managed Sharing
For records that need exceptional sharing beyond what the standard rules express, Manual Sharing lets a user explicitly share a specific record with another user or group. The shared user gets read or read/write access for that one record. Apex Managed Sharing extends the concept programmatically: an Apex trigger or class can grant or revoke sharing on specific records based on custom logic. Both are typically used for edge cases (a one-off escalation, a partner deal where a specific external user needs visibility) rather than as primary sharing mechanisms. Heavy use of Apex Sharing signals that the standard sharing model is insufficient for the use case.
Account Teams, Opportunity Teams, Case Teams
Teams are pre-built sharing patterns for collaborative work on Accounts, Opportunities, and Cases. An Account Team member gets read or read/write access to the Account plus any related Opportunities and Cases based on the team's configured access levels. Opportunity Teams work similarly at the Opportunity level. Case Teams give multiple agents collaborative access on a single Case. Teams are configured per record (the record owner adds team members manually) or via Account Team Templates that pre-populate teams when an Account is owned by specific users. Teams are useful for the common scenario where multiple people need shared ownership of strategic accounts.
Public Groups, Queues, and Permission Sets
Public Groups and Queues are reusable collections of users and roles that sharing rules can target. A Public Group might contain all sales engineers; a sharing rule then shares specific records with the group, eliminating the need to specify each user individually. Queues are similar but also serve as work-distribution targets (Lead Queue, Case Queue) where records sit until claimed. Permission Sets layer additional object permissions on top of the base profile, which combined with the sharing model gives admins fine-grained control over what each user can do. The combination of Public Groups, Queues, Permission Sets, and Sharing Rules is what makes the sharing model expressive enough for complex business scenarios.
Territory-Based Sharing and external sharing
For sales organizations with territory structures (geographic, vertical, or account-based), Enterprise Territory Management adds a parallel sharing dimension where records share based on territory assignment rather than just record ownership. A rep assigned to multiple territories sees records belonging to any of their territories. External sharing (for Partner Users and Customer Community Users) layers on the External Sharing Model with its own OWD settings and sharing rules, scoped separately from the internal sharing model. Multi-cloud orgs that share Salesforce data with partners and customers carry both an internal sharing model and an external one, with careful design ensuring partners see only what they should and never more.
Performance and scale considerations for the sharing model
The sharing model has real performance implications at scale. Every record on a Private OWD object carries one or more sharing rows in the underlying database, with the system maintaining these rows automatically as ownership and sharing rule criteria change. For objects with hundreds of millions of records, the sharing-row count can grow into the billions, which affects query performance, sharing recalculation duration, and storage. Salesforce provides tools for analyzing sharing performance: the Sharing Recalculation status page, the Object Manager Sharing Settings tab, and specific limits on the number of sharing rules per object. Architects designing for scale need to consider the sharing implications upfront, sometimes choosing simpler sharing patterns (Public Read Only OWD with profile-level FLS) over more flexible patterns (Private OWD with extensive sharing rules) to keep the system performant. Watching sharing-row growth on the largest objects monthly is the right operational discipline; when growth becomes problematic, restructuring the sharing model to use territory hierarchies or alternative patterns can dramatically reduce the row count and improve performance.
Design and maintain a Salesforce sharing model
Designing the sharing model is an architectural exercise that spans business requirements gathering, OWD selection, rule design, role hierarchy alignment, and ongoing maintenance. The workflow below covers the standard sequence for a new sharing design.
- Document business sharing requirements
Talk to each stakeholder group about what records they need to see and edit. Capture the requirements as a matrix: object, user group, access level (read, edit, none). Identify cross-team scenarios (sales engineers need visibility to all closed-won deals, partner managers need visibility to deals in their territory). Document any compliance constraints (HR data is private, financial data is restricted to specific roles). This requirements document becomes the design foundation; without it, the sharing model is built on assumptions that bite later.
- Set Organization-Wide Defaults intentionally
From Setup, navigate to Sharing Settings. Set the OWD for each major object based on the design. Start more restrictive than you think you need; opening up sharing later is easier than tightening it. Private is the standard starting point for sensitive objects (Account, Opportunity, Case); Public Read Only is appropriate for reference data. Save the OWD changes and confirm in sandbox that users see the expected records (or do not see records they should not).
- Configure Role Hierarchy and Sharing Rules
Build or update the Role Hierarchy to match the org's reporting structure. Add Sharing Rules to open up cross-team access per the requirements matrix: criteria-based for record-content sharing (all Opportunities in Region West to West sales engineers), ownership-based for role-based sharing (records owned by Sales Reps to Sales Operations). For each rule, choose the right target (Role, Role and Subordinates, Public Group, Queue). Save and let the sharing recalculation complete before testing.
- Test, audit, and document
Log in as test users from each user group and confirm they see exactly the records they should and no others. Audit edge cases: new hires, role changes, ownership transfers. Document the sharing design in the org's architecture wiki with a diagram of role hierarchy, a list of sharing rules per object, and the rationale for each design choice. Schedule a quarterly review with the business stakeholders to confirm the sharing still matches operational needs. Update the design as the business evolves.
- OWD changes trigger sharing recalculation for every record on the object. In large orgs, this can take hours and slow other operations.
- The Role Hierarchy must match the operating reporting structure. Misalignment causes records to roll up to the wrong managers and creates visibility complaints.
- Sharing is additive, not subtractive. There is no way to restrict access through a sharing rule; only to grant more access.
- Manual Sharing entries do not survive ownership transfers. Build into your runbook the steps to re-apply any manual shares after a transfer.
- Apex Managed Sharing requires careful design to avoid unintended access grants. Code review by a security-aware reviewer is essential.
Trust & references
Cross-checked against the following references.
- Organization-Wide Sharing DefaultsSalesforce Help
Straight from the source - Salesforce's reference material on Sharing Model.
- Data Access OverviewSalesforce Help
- Manage the Sharing ModelSalesforce Help
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 the Sharing Model?
Q2. Why does it matter?
Q3. When should you review it?
Discussion
Loading discussion…