The best Salesforce sharing model starts closed and opens access on purpose. Set org-wide defaults to the most restrictive level your users can work with, then use the role hierarchy and Salesforce sharing rules to grant extra access only where there is a business reason. Sharing rules can only widen access, never narrow it, so the order you build in matters.
This guide walks through each layer, the practices that keep an org easy to understand, and the mistakes that cause both over-sharing and "I can't see my client" tickets. Details were checked against Salesforce documentation in November 2026.
The four layers of access
Salesforce's architecture guidance says access is enforced through four layers: organization, object, field and record (Salesforce Architects, Trust, checked November 2026).
- Organization: login constraints and which features are on.
- Object: whether a user can create, read, edit or delete a type of record.
- Field: which fields on that object are visible or editable.
- Record: which specific records the user can see.
The sharing model controls the fourth layer. Profiles and permission sets control the first three. A common mistake is trying to fix a record-access problem with object permissions, or the reverse. Our post on permission sets vs. profiles covers the other half.
Start with org-wide defaults
Org-wide defaults (OWD) set the baseline access users have to records they do not own. Salesforce's platform sharing guidance says to start restrictive and open access selectively with other tools (Salesforce Architects, Platform Sharing Architecture, checked November 2026).
A practical rule: set the OWD for each object to the access your most restricted user should have. For objects holding sensitive client information, that is usually Private. For reference data that everyone needs, such as a program list, Public Read Only may be fine.
Two cautions:
- Changing OWD triggers sharing recalculation, which can take a long time on large data volumes. Plan changes for a quiet period and test in a sandbox first.
- Do not loosen OWD to solve one person's problem. Use a sharing rule or a team for the exception instead.
Use the role hierarchy with care
The role hierarchy lets managers see the records owned by the people below them. Salesforce states it ensures managers have access to the same data as their employees, regardless of the OWD setting.
Best practices:
- Model roles around data access, not the org chart. Salesforce advises building each role around a level of data access. A role exists to give visibility, not to mirror job titles.
- Keep it shallow. Salesforce suggests no more than 10 levels of branches.
- Remember peers do not see each other. Two people in the same role do not automatically see each other's records.
- Check the "Grant Access Using Hierarchies" setting on custom objects. It is on by default. Turning it off stops users higher in the hierarchy from inheriting access, which can be useful for a sensitive object where managers do not need to see everything.
Sharing rules: the exception tool
Sharing rules give additional users access to records they do not own, and they apply when the OWD is Private or Public Read Only (Salesforce Help, Sharing and Record Access Features, checked November 2026). There are two main types:
- Owner-based rules share records based on who owns them. Example: share records owned by the intake team with the care coordination team.
- Criteria-based rules share records based on field values, regardless of owner. Example: share records where Program equals a given program with that program's staff group.
Good habits:
- Share to public groups or roles, not to individuals. When someone moves teams, you change the group, not twenty rules.
- Give rules clear names and descriptions that state the business reason. Future you will need it.
- Prefer read access unless the group genuinely edits the records.
- Watch the limits. Salesforce lists 300 owner-based sharing rules per object and 50 criteria-based and guest user rules combined per object. If you are close, the design probably needs rethinking.
- Be especially careful with guest user sharing rules. Salesforce notes they grant broad access to unauthenticated users and carry significant exposure risk.
Other tools worth knowing
- Manual sharing: record owners or admins can share a single record. It is useful for one-off cases, but it disappears when the owner changes, so do not build a process on it.
- Teams: account, opportunity and case teams give a group access to one record. Salesforce notes there is only one team per record.
- Restriction rules: unlike sharing rules, these narrow access. Salesforce says they apply to custom objects, external objects, contracts, events, tasks, time sheets and time sheet entries, with limits by edition. They can help when a group should see only a subset of records.
- Apex managed sharing: for cases where declarative tools cannot meet the requirement, or an outside system is the source of truth for access.
- Permissions that bypass sharing: Salesforce notes that View All and Modify All skip sharing rules and settings, and recommends the object-level versions over the org-wide View All Data and Modify All Data. Review who holds these. Our post on finding over-permissioned users shows how.
Watch for performance traps
Salesforce's guidance calls out two issues for larger orgs:
- Data skew: when one parent record has a very large number of child records, performance can degrade. Salesforce mentions a ratio around 1 to 10,000 as a point to avoid.
- Ownership skew: when one user owns a very large number of records, Salesforce advises keeping that user out of the role hierarchy or placing their role at the top in its own branch. A common cause is a generic "integration" or "admin" user that owns everything.
Also avoid frequent structural changes. Salesforce suggests making hierarchy changes no more than quarterly, planned and tested in a sandbox.
Common mistakes we see
- Setting OWD to Public Read/Write "to stop the complaints."
- Dozens of one-off sharing rules that nobody can explain.
- A deep role hierarchy copied from an org chart.
- Granting View All or Modify All to a whole team for convenience.
- No written record of why each rule exists.
How to troubleshoot "I can't see this record"
Salesforce's guidance gives an order that works well:
- Does the user have object permission?
- How does the user's role compare with the owner's role?
- Are they in different branches of the hierarchy?
- Is there a sharing rule, and is the user in the right public group?
- Is a team used, and is the user on it?
- Was a manual share lost when ownership changed?
Work from the top and you will find most problems in a few minutes.
Document it
A sharing model nobody can explain is hard to defend in an audit. Write down, for each sensitive object: the OWD, who can see what and why, and which rules exist. Troppus's Security Framework Design product provides governance templates for roles, profiles and sharing rules with audit-ready documentation, and our Apex Security Check looks for over-permissioning. You can see both on the products page.
Frequently asked questions
What is the difference between a sharing rule and a permission set?
A permission set controls what a user can do with an object and its fields. A sharing rule controls which records the user can see. You usually need both.
Can a sharing rule make access more restrictive?
No. Sharing rules only grant additional access beyond the OWD and role hierarchy. To narrow access you lower the OWD or use restriction rules where they are available.
Should every object be Private?
Not necessarily. Use the most restrictive setting your users can work with. Objects that hold sensitive client or health information are usually Private. Shared reference data can be more open.
How many sharing rules is too many?
Salesforce sets per-object limits, but long before you hit them a lot of rules becomes hard to maintain. If you cannot explain each rule in one sentence, consolidate.
Does the sharing model matter for HIPAA or funder audits?
It is one of your main controls for limiting who sees client data, so auditors often ask about it. This is not legal or compliance advice. Our post on Salesforce permissions and PHI goes deeper on health data.
Want a second opinion on your sharing model?
We can review your org-wide defaults, hierarchy and sharing rules, and tell you where access is too open or too tight. Book a free Salesforce health check.