Sharing
Sharing is the Salesforce record-level access framework that decides which users can read or edit which individual records.
Definition
Sharing is the Salesforce record-level access framework that decides which users can read or edit which individual records. It sits one layer above field-level security (which controls columns) and one layer below profile and permission set object permissions (which control whole-object access). Where profiles decide whether you can see Accounts at all, Sharing decides which specific Account records you can see.
The framework is layered. Org-wide defaults set the baseline access for an object. Role hierarchy grants upward visibility to managers. Sharing rules open access to defined groups based on owner or criteria. Manual sharing lets owners grant per-record access. Teams and territories grant deal-specific or geographic access. Apex managed sharing handles cases the declarative tools cannot cover. Every layer can only widen access from the OWD baseline. Nothing in this stack can revoke access that profiles or permissions grant directly.
How the Salesforce sharing model decides who sees what
The five sharing layers and their evaluation order
When a user opens a record, Salesforce evaluates sharing in a specific order. First, it checks whether the user owns the record. Owners always have full access. Then it checks the OWD for that object. If the OWD is Public Read/Write, the user is in. If not, Salesforce checks the role hierarchy (when Grant Access Using Hierarchies is on), sharing rules, teams, territories, manual shares, and Apex managed shares. The most permissive grant wins, so Read/Write beats Read Only. Order matters for performance because Salesforce can stop checking once it finds enough access. Functionally, the user sees the highest level any layer grants them.
Org-Wide Defaults: the baseline sharing extends from
OWDs are the most restrictive setting in the model. They define what access users have to records they do not own, before any sharing rules apply. Choices range from Private (only the owner and people above them in the hierarchy see it), to Public Read Only, to Public Read/Write. Some objects support a Controlled by Parent setting that inherits sharing from the master record. The rule of thumb is to set OWDs as restrictively as the business allows, then open up access deliberately through the other layers. Tightening OWDs after launch is painful because it retroactively removes access and forces sharing recalculation across millions of rows.
Role Hierarchy and upward visibility
The role hierarchy grants managers automatic visibility into the records owned by people below them. This is on by default for every standard object and most custom objects. The behaviour is controlled by the Grant Access Using Hierarchies checkbox on each custom object. Turn it off when records should not roll up to managers (for example, employee performance reviews owned by the employee). Standard objects always grant access via hierarchy and the checkbox cannot be cleared for them. Role hierarchy is the cheapest way to grant manager visibility because it requires no rule maintenance as people move teams, but it grants Read/Write, not Read Only.
Sharing rules: criteria-based and owner-based grants
Sharing rules grant access to defined groups of users. Owner-based rules share records owned by members of one group with another group, for example records owned by EMEA Sales Users shared to EMEA Service Users with Read Only. Criteria-based rules share records matching field criteria with a group, for example records where Industry equals Healthcare shared to the Healthcare Specialist queue with Read/Write. Sharing rules are declarative and recalculate automatically when group membership or criteria changes. The catch is the 300-rules-per-object hard limit, which large orgs with many overlapping geographies or segments can hit. When you approach that limit, the right move is usually to consolidate sharing through public groups instead of stacking more rules.
Manual sharing, the Sharing button, and Apex managed sharing
Manual sharing lets a record owner (or someone above the owner in the hierarchy) share an individual record with a specific user or group. In Lightning Experience, this is the Sharing action on the record page. The grant survives until the owner changes, at which point manual shares are wiped. Manual sharing is the right tool for true one-off grants like a legal counsel needing access to one specific contract. It is the wrong tool for recurring patterns, which belong in sharing rules. Apex managed sharing is the programmatic equivalent for grants that change automatically based on business logic too complex for criteria-based rules. Because you control the rowCause when you insert the share, Apex managed shares survive owner changes.
Teams and territories for deal-specific and geographic grants
Account Teams, Opportunity Teams, and Case Teams add a deal-specific membership concept. Adding a user as an Opportunity Team Member grants them access to that one Opportunity at the level the team role specifies. Teams are declarative, fast to set up, and survive owner changes. Territory Management grants access by geographic or segment territory, with users assigned to territories and records (mostly Accounts) assigned to the same territories. Territory grants behave like a parallel role hierarchy for the assigned objects. They are the right tool when geography drives access more than reporting lines, which is common in regional sales, field service, and partner-channel orgs.
Implicit sharing you cannot turn off
Salesforce has built-in implicit sharing rules that you cannot disable. Read access to an Account is automatically granted to anyone with access to a child Contact, Opportunity, or Case. Access to an Account grants Read on child records the other way too. These rules exist because the data model would otherwise produce constant access errors as users follow lookups. Implicit sharing is the reason an apparently overshared Account in a sharing audit is often the result of a user owning a related Contact rather than the Account directly. When you investigate unexpected access, check children before assuming the OWD or a rule is wrong.
Design and roll out a sharing model
Designing the sharing model is a one-shot decision for the life of the org. The steps below cover the discovery, configuration, and rollout for a new org or a sharing-model overhaul.
- Map data sensitivity per object
For each object, classify data sensitivity as high, medium, or low. Map which user populations should see each object. The decision matrix tells you which OWD makes sense before you set anything.
- Set Organization-Wide Defaults
In Setup, Sharing Settings, edit Organization-Wide Defaults. Choose Private for sensitive data, Public Read Only or Public Read/Write for shared data. Set the External default to Private even when internal is Public, especially for Experience Cloud users.
- Configure role hierarchy and Grant Access Using Hierarchies
Build the role hierarchy to reflect reporting relationships. For custom objects where records should not roll up to managers, uncheck Grant Access Using Hierarchies on the object definition. Standard objects always grant access via hierarchy.
- Add sharing rules for cross-group access
Create owner-based rules to share between groups (region to region, team to team). Create criteria-based rules to share records matching field criteria such as a Status or Type value. Stay under the 300-rules-per-object limit.
- Enable teams and territories where deal access matters
Turn on Account Teams or Opportunity Teams in Setup when ad-hoc collaborators need access to specific records. Enterprise Territory Management is the right call when geography or segment drives access patterns.
- Document the model and test in a sandbox
Write the sharing design down so future admins can read what you intended. Test the model with seed users in a full sandbox before promoting to production. Sharing recalculation can take hours on a real-data sandbox, which is itself a useful signal.
Per-object checkbox. Off means managers do not automatically see direct reports' records. Standard objects ignore this setting and always grant hierarchy access.
Independent default for Experience Cloud users. Set Private even when internal is Public Read/Write to avoid accidental external exposure.
Setup tool that pauses sharing recalc during bulk data loads. Resume the calc after the load finishes to avoid hours of locked-row errors.
- Tightening OWDs is retroactive and triggers a full sharing recalc. On a million-row object this can take hours and locks rows during the recalc.
- External OWDs are independent. Experience Cloud sites have surprised many orgs that set internal OWD to Public Read/Write and forgot the external default was still Public Read Only.
- Sharing rules have a 300-per-object hard limit. Hitting it usually means the design relies too heavily on criteria-based rules instead of role hierarchy or teams.
Trust & references
Cross-checked against the following references.
- Sharing and Record Access FeaturesSalesforce Help
- Sharing RulesSalesforce Help
- Defer Sharing CalculationsSalesforce Help
- Record-Level Access Architecture Decision GuideSalesforce Architects
Straight from the source - Salesforce's reference material on Sharing.
- Sharing and Record Access FeaturesSalesforce Help
- Sharing RulesSalesforce Help
- Apex Managed SharingSalesforce Developers
Hands-on resources to go deeper on Sharing.
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 Sharing in Salesforce?
Q2. What are the sharing mechanisms?
Q3. What's the starting principle?
Discussion
Loading discussion…