The Sharing Model Nobody Designed: The Most Ignored Architecture Decision in Salesforce
How to assess and fix your sharing and visibility settings before they become a compliance problem
I ask every new client the same question: "Who designed your sharing model?" The most common answer: silence. The second most common: "What's a sharing model?"
A healthcare organization hired me last year to investigate a compliance concern. During an internal audit, they discovered that clinical staff could see billing records for every patient in the system. Case managers could view physician notes. Administrative assistants had read access to diagnosis codes. The compliance officer wanted to know how long this had been the case.
The answer: since implementation. Four years earlier, a consulting partner had set up the org with Organization-Wide Defaults (OWD) at Public Read/Write for every object. The rationale documented in the implementation notes: "Client wants all users to have access to all data for ease of use." The client at the time was a team of 15 people. Four years later, the org had grown to 120 users across 8 departments. The sharing settings never changed.
Redesigning the sharing model after 4 years of development on a flat structure cost $40,000. Role hierarchy design, sharing rule creation, permission set restructuring, Flow updates (several Flows queried records across the org and broke when visibility was restricted), report reconfiguration (reports that showed all records now needed to be scoped by role), and user acceptance testing across 8 departments. The entire project took 6 weeks.
The same sharing model design, done correctly during the original implementation, would have cost approximately $5,000 and taken 3-4 days.
Why Sharing Models Get Neglected
Implementation Partners Skip It
Sharing model design is the least visible deliverable in a Salesforce implementation. It doesn't produce a dashboard. It doesn't automate a process. It sets permissions that users never see unless they try to access something they shouldn't. Implementation partners often deprioritize it because clients don't ask about it. The default settings work. Nobody complains until they realize the default settings expose data they didn't intend to share.
The "Everyone Needs to See Everything" Assumption
Small orgs start with a flat structure because everyone wears multiple hats. The admin is also the sales manager is also the support lead. Restricting access feels counterproductive. The assumption is that as the org grows, someone will redesign the sharing model. Nobody does because nobody is hired specifically to do it.
Nobody Understands the Components
Salesforce's sharing and visibility model has four layers: Organization-Wide Defaults, Role Hierarchy, Sharing Rules, and Permission Sets/Permission Set Groups. Each layer builds on the previous one. Understanding how they interact requires architectural knowledge that most admins develop over years, not weeks. Junior admins inherit the settings and don't modify them because they're not confident about what will break.
Fear of Breaking Existing Functionality
Changing OWD from Public Read/Write to Private is not a simple toggle. It immediately restricts access for every user on every record for that object. Any Flow that queries records across the org will fail if the running user no longer has visibility. Any report that shows all records will show only the records the running user can see. Any dashboard will change. The cascading impact discourages admins from making the change even when they know the current settings are wrong.
How to Assess Your Current Sharing Model
Step 1: Check Organization-Wide Defaults
Navigate to: Setup → Security → Sharing Settings
This page shows the OWD for every standard and custom object. The OWD determines the baseline level of access that all users have to all records of that object type.
| OWD Setting | What It Means |
|---|---|
| Private | Users can only see records they own, records owned by users below them in the role hierarchy, and records shared with them via sharing rules |
| Public Read Only | All users can see all records but can only edit records they own |
| Public Read/Write | All users can see and edit all records |
| Controlled by Parent | Access is determined by the parent record (used for detail objects in master-detail relationships) |
For most orgs with 50+ users and multiple departments, the recommended OWD for sensitive objects is Private. Objects like Account, Contact, Opportunity, and Case should be Private unless there's a documented business reason for broader access.
Record what the current OWD is for every object. Flag any object set to Public Read/Write that contains sensitive data.
Step 2: Review the Role Hierarchy
Navigate to: Setup → Users → Roles
The role hierarchy determines who can see records owned by whom. Users in higher roles can see records owned by users in lower roles (unless the "Grant Access Using Hierarchies" checkbox is disabled for custom objects).
Check for:
- Does the role hierarchy match the actual organizational structure?
- Are there roles with no users assigned? (Legacy roles from former employees)
- Are there users assigned to the wrong role? (Common after organizational restructuring)
- Is the hierarchy too flat? (Everyone in the same role means the hierarchy provides no incremental access)
- Is the hierarchy too deep? (Excessive nesting creates complexity without value)
Run this query to see users and their roles:
SELECT Name, UserRole.Name, IsActive
FROM User
WHERE IsActive = true
ORDER BY UserRole.Name
Step 3: Inventory Sharing Rules
Navigate to: Setup → Security → Sharing Settings → scroll down to sharing rules for each object
Sharing rules grant additional access beyond what OWD and role hierarchy provide. They come in two types:
Criteria-based sharing rules: Share records based on field values. Example: "Share all Opportunities where Region = 'East' with the East Sales Team role."
Owner-based sharing rules: Share records based on who owns them. Example: "Share all Cases owned by Support Tier 1 with Support Tier 2."
For each sharing rule, document:
- Which object it applies to
- The criteria or owner condition
- Who it shares with (role, role and subordinates, public group)
- The access level granted (Read Only, Read/Write)
- Whether it's still needed (business requirements may have changed)
Step 4: Audit Permission Sets and Permission Set Groups
Navigate to: Setup → Users → Permission Sets
Permission sets grant specific permissions to individual users or groups without changing their profile. With Salesforce's move away from profiles toward permission sets (accelerated in Winter '26), this is increasingly where access is controlled.
For each permission set, check:
- What object-level permissions does it grant? (Read, Create, Edit, Delete)
- What field-level security does it set? (Which fields are visible, which are editable)
- How many users are assigned to it?
- Is it part of a Permission Set Group?
Run this query for a high-level view:
SELECT PermissionSet.Name, Assignee.Name
FROM PermissionSetAssignment
WHERE PermissionSet.IsOwnedByProfile = false
ORDER BY PermissionSet.Name
Step 5: Test with a Non-Admin User
The most revealing test: log in as a non-admin user and see what they can see.
Navigate to: Setup → Users → find a standard user → click "Login" (if Login As is enabled)
As that user, check:
- Can they see records from other departments?
- Can they edit records they shouldn't modify?
- Can they see fields with sensitive data (salary, SSN, medical information)?
- Do reports show them records outside their expected scope?
This 10-minute test reveals more about your sharing model than any configuration review.
How to Fix a Wide-Open Sharing Model
Restricting an existing sharing model is a project, not a setting change. Here's the sequence.
Phase 1: Design the target state (1-2 weeks)
Map each user role to the data they should and shouldn't access. Create a matrix:
| Object | Role A | Role B | Role C |
|---|---|---|---|
| Account | Read/Write Own | Read All | No Access |
| Opportunity | Read/Write Own | Read Own | No Access |
| Case | No Access | Read/Write Own | Read All |
This matrix becomes your specification for OWD settings, role hierarchy structure, and sharing rules.
Phase 2: Build in sandbox (1-2 weeks)
In a sandbox, implement the new OWD settings, adjust the role hierarchy, create sharing rules, and configure permission sets according to the design matrix. Test every user role by logging in as a representative user and verifying they can see what they should and cannot see what they shouldn't.
Test every automation. Flows that run in System Context bypass sharing. Flows that run in User Context respect sharing. If a Flow queries records that the running user can no longer see, the Flow will return no results or throw an error. Identify and fix these Flows before deployment.
Test every report. Reports respect sharing rules by default. Reports that previously showed all records will now show only the records visible to the running user. Dashboard components will change. The sales VP's "All Pipeline" dashboard will only show pipeline for their subordinates unless the report is configured to run as a specific user.
Phase 3: Deploy and communicate (1 week)
Deploy the sharing model changes to production during a low-traffic window. Communicate the changes to all users before deployment: "You may notice that some records are no longer visible. This is intentional. If you need access to records outside your department, contact your Salesforce admin."
Phase 4: Monitor and adjust (2 weeks)
After deployment, monitor for access requests. Some legitimate access needs will surface that weren't captured in the design matrix. Create sharing rules or permission sets to address these needs. Track all adjustments in the change log.
How to Prevent Sharing Model Neglect
Annual sharing model review: Once per year, review the OWD settings, role hierarchy, and sharing rules against the current organizational structure. Departments merge. Roles change. The sharing model should change with them.
New employee checklist: When a new employee joins, verify that their role, permission sets, and public group memberships are correct before granting system access. Don't copy the previous employee's settings blindly. Verify.
Compliance checkpoint: For orgs in regulated industries (healthcare, finance, government), include sharing model verification in quarterly compliance audits. Document who can see what data and compare it against regulatory requirements (HIPAA, SOX, GDPR).
Permission set naming convention: Name permission sets descriptively: [Department][AccessLevel][Purpose]. Example: Finance_ReadWrite_BillingRecords. Ambiguous names like "Custom Permission Set 1" make auditing impossible.
Download the Sharing Model Assessment Template
The Sharing Model Assessment Template is an editable document with sections for current OWD settings, role hierarchy mapping, sharing rule inventory, permission set audit, and a target state design matrix. Fill it out, compare current state against target state, and scope the remediation work.
Download it below. It's free.
Part 6 of 10 in the series: What Your Salesforce Org Says About Your Company.
