Salesforce decides record visibility in layers. Permissions say which objects and fields a user can touch at all. Organization-wide defaults then set the floor for each object's records. The role hierarchy, sharing rules, teams, territories and manual shares only add access above that floor. Restriction and scoping rules can narrow what people see. When users see too much, the floor is usually too open. When they see too little, an opening layer is missing.
Which layers decide whether a user can see a record?
Two separate questions decide it: can this user open this kind of object, and can they open this particular row? Object and field permissions answer the first; the sharing model answers the second.
Object permissions such as Read, Create and Edit come from profiles and permission sets. If a user lacks Read on Opportunity, no sharing rule will ever show them an opportunity. Our permission set migration article covers that layer; this one stays on record access.
Two object permissions skip the sharing model completely: View All and Modify All, plus the org-wide View All Data and Modify All Data. Check for these first whenever someone sees records they should not.
How should we set organization-wide defaults?
Set each object's default to the most restrictive level that any regular user needs, then open access with other tools. Salesforce is explicit that later layers can only add access, never remove it below the default.
Most objects offer Private, Public Read Only and Public Read/Write. Child objects in a master-detail relationship use Controlled by Parent. Work through each object with three questions:
- Is there any group of users who must not see some of these records? If yes, the default must be Private.
- Do most users need to read everything but edit only their own? Public Read Only fits.
- Is this reference data that everyone maintains together? Public Read/Write may be fine.
Salesforce also keeps a separate external default for portal and partner users on objects such as Account, Contact, Case, Opportunity and custom objects. The external level can be equal to or tighter than the internal level, never looser. A common pattern is internal Public Read Only with external Private.
Should the role hierarchy match our org chart?
Only where managers genuinely need their reports' records. The hierarchy is a data access tool, so it should follow who must see whose records, not job titles.
By default, a user inherits access to records owned by everyone below them in the hierarchy. On standard objects this behavior is always on. For custom objects, you can clear Grant Access Using Hierarchies so managers do not inherit access automatically.
Mirroring the org chart works for a classic sales team: rep, manager, director, VP. It breaks down when executives without Salesforce licenses sit in the tree, or when support, finance and sales leaders sit side by side. Collapse levels where nobody owns records. Keep peers who must not see each other's data in sibling branches. If you are adding roles purely to carve up coverage, read our territory management guide before you go further.
When do we need sharing rules and public groups?
Use sharing rules when a whole set of users needs access that ownership and the hierarchy do not give them. They open records sideways, across branches.
Owner-based rules share records owned by one role or group with another. Criteria-based rules share records whose field values match, such as Region equals West or Type equals Partner. Criteria rules are easier to reason about because they follow the data rather than the people.
Share with public groups rather than individual roles where you can. A group called Finance Reviewers survives a reorganization better than a rule pointing at three named roles. Keep groups few and named after a business purpose.
What do teams, manual sharing and Apex sharing add?
They handle access for one record at a time instead of for whole populations. Use them for exceptions, not as the backbone of the model.
- Account, opportunity and case teams: list the people who work a specific record, each with an access level and a team role such as sales engineer or escalation lead.
- Manual sharing: the owner, someone above them in the hierarchy or an admin shares a single record using the Sharing button. Manual shares can be lost when ownership changes, so do not build processes on them.
- Apex managed sharing: code writes share records, often with a custom sharing reason on custom objects. Reserve it for rules no declarative tool can express, and document who maintains it.
How do restriction rules and scoping rules differ?
Restriction rules remove records from what a user can access. Scoping rules only change which records a user sees by default in list views, reports and queries.
Restriction rules filter access after all the sharing layers have run. Salesforce documents them for custom objects, external objects, quotes, contracts, events, tasks, time sheets and time sheet entries. They are listed for Enterprise, Performance, Unlimited and Developer editions, with a small cap on active rules per object. They suit cases like hiding confidential tasks from most staff.
Scoping rules do not change security; a user can still reach other records they have access to. They cover objects such as accounts, opportunities, cases, contacts and leads, and are listed for Performance, Unlimited and Developer editions. Coverage shifts between releases; check current objects and editions with your Salesforce account team first.
Where do territories, implicit sharing and portal users fit?
These mechanisms grant access you did not configure directly, which is why they surprise people during audits.
Sales Territories opens accounts and opportunities to the sellers assigned to each territory, independent of roles. It earns its overhead when several sellers share one account.
Implicit sharing is built in and cannot be switched off. A user who can see a contact, opportunity or case also gets read access to its parent account. The account owner, and roles above them, can also reach that account's child records, depending on settings for each role.
External users in Experience Cloud follow their own rules. High-volume licenses such as Customer Community have no roles, so they get access through sharing sets that match records to the user's account or contact. Partner and Customer Community Plus users can have roles and be included in sharing rules.
Can our sharing design slow Salesforce down?
Yes. Sharing is calculated and stored, so some designs make saves, data loads and recalculations slow or prone to lock errors.
Salesforce's enterprise-scale guidance flags two kinds of data skew around the 10,000-record mark:
- Ownership skew: one user owns more than about 10,000 records of an object, often an integration or default owner. Give that user no role, or one at the top of a separate branch, and keep them out of groups used in sharing rules.
- Parent-child skew: one parent record has more than about 10,000 children, such as an Unassigned account holding thousands of contacts. Spread the children across more parents.
Deep, wide hierarchies and many overlapping groups also lengthen recalculation after any change to roles or rules. For large reorganizations, Salesforce offers deferred sharing calculation, which an admin can pause and resume. It is not on by default; Salesforce Support enables it. Always run a full recalculation afterwards, or access can be left inconsistent.
How do we find out why someone can see a record?
Open the record and use the Sharing Hierarchy action in Lightning Experience. It lists who has access, and the View link beside a user shows their access level and the reason.
If that action is missing, add it to the page layout's actions. Then follow this order when debugging:
- Check the user's permission sets and profile for View All, Modify All or View All Data on that object.
- Check the object's organization-wide default.
- Check whether the user sits above the owner in the role hierarchy.
- Check sharing rules and the groups that feed them.
- Check teams, territories, manual shares and implicit access from child records.
What does each sharing mechanism do best?
| Mechanism | What it does | Best use | Common mistake |
|---|---|---|---|
| Organization-wide defaults | Sets the baseline access for every record of an object | Private where any group must be kept out | Leaving objects Public Read/Write from setup and never revisiting |
| Role hierarchy | Lets users see records owned by people below them | Manager visibility over their own team's data | Copying the full org chart, including roles nobody uses |
| Sharing rules | Opens groups of records to roles or groups by owner or criteria | Cross-team access such as finance reading closed deals | Dozens of overlapping owner-based rules nobody can explain |
| Public groups | Named collections of users, roles and other groups | Stable targets for rules that outlast reorganizations | One group per request, with no owner or purpose |
| Teams | Adds named people to a single account, opportunity or case | Pursuit and escalation teams on specific records | Using teams to fix a default that is too tight |
| Manual sharing | Shares one record with one user or group | Rare, short-lived exceptions | Relying on shares that vanish when the owner changes |
| Apex managed sharing | Code creates shares for complex logic | Rules no declarative tool can express | Undocumented code nobody maintains |
| Restriction rules | Filters out records a user could otherwise access | Hiding sensitive tasks, events or custom records | Assuming they cover every standard object |
| Scoping rules | Narrows default views without changing security | Helping users focus on their own segment | Treating them as a security control |
| Sharing sets | Grants portal users access via their account or contact | High-volume Experience Cloud users | Expecting sharing rules to work for those licenses |
How should we design or clean up a sharing model?
Design from the data inward: decide who must not see what, set defaults to protect that, then add the fewest opening layers that meet real needs.
- List every object that holds sensitive or competitive data and who must be kept out of it.
- Set organization-wide defaults per object, internal and external, against that list.
- Draw the role hierarchy around data ownership, and keep it shallow.
- Add criteria-based sharing rules to public groups for cross-team needs.
- Use teams for record-level collaboration and keep manual sharing rare.
- Test with real user personas before go-live, using the Sharing Hierarchy view.
For an existing org, a sensible phase one is an inventory, not a rebuild. Export the defaults, roles, groups and sharing rules. Find users with View All Data or object-level View All. Check for owners and parents near the skew thresholds. Remove unused roles, empty groups and rules that point at them. Then tighten one sensitive object at a time, testing each change with affected users.
A multi-agent insurance agency we worked with needed agents kept out of each other's clients when it moved off spreadsheets to Sales Cloud. Org-wide defaults went to private, and rules expose closed-lost records once 14 days have passed. That private model was built to meet the agency's security requirements.
