Salesforce Sharing & Visibility: A Pragmatic Blueprint

90% of Salesforce orgs have overly permissive access. Users see data they shouldn't. Compliance audits fail. Security breaches happen. This blueprint fixes that.

After designing sharing models for 50+ enterprises—from 100-user startups to 50,000-user Fortune 500s—I've developed a pragmatic approach that balances security, usability, and performance. No theory. Just what works in production.

The Salesforce Security Model: 5 Layers of Control

Step 1: Set Your OWD Foundation

Organization-Wide Defaults are your starting point. Get this wrong, and everything else becomes a band-aid.

Step 2: Design Your Role Hierarchy

Your role hierarchy should mirror your organizational structure, but with pragmatic adjustments for Salesforce limitations.

Role Hierarchy Design Principles:

1. Keep it shallow: Maximum 10 levels. Deep hierarchies kill performance.
2. Avoid single-child roles: Consolidate where possible.
3. Use naming conventions: [Department]_[Level]_[Region] (e.g., Sales_Manager_West)
4. Plan for growth: Leave room for expansion without restructuring.
5. Document everything: Future admins need to understand your logic.

CEO
├── Sales_EVP
│   ├── Sales_VP_Americas
│   │   ├── Sales_Director_West
│   │   │   ├── Sales_Manager_California
│   │   │   │   └── Sales_Rep_California
│   │   │   └── Sales_Manager_PacificNW
│   │   │       └── Sales_Rep_PacificNW
│   │   └── Sales_Director_East
│   │       ├── Sales_Manager_Northeast
│   │       │   └── Sales_Rep_Northeast
│   │       └── Sales_Manager_Southeast
│   │           └── Sales_Rep_Southeast
│   └── Sales_VP_EMEA
│       └── [Similar structure]
├── Service_EVP
│   └── [Service hierarchy]
└── Operations_EVP
    └── [Operations hierarchy]

Step 3: Master Permission Sets and Groups

Forget profiles for permissions. Use them only for page layouts and login hours. Permission Sets and Permission Set Groups are your future.

Permission Set Strategy:

1. Create functional permission sets:
   • Lead_Management
   • Opportunity_Edit
   • Report_Builder
   • Dashboard_Viewer
2. Bundle into Permission Set Groups by role:
   • Sales_Rep_PSG (Lead_Management + Opportunity_Edit)
   • Sales_Manager_PSG (Sales_Rep_PSG + Report_Builder + Dashboard_Viewer)
3. Assign groups to users based on job function

Step 4: Implement Sharing Rules Strategically

Sharing rules are powerful but dangerous. Each rule adds complexity and can impact performance.

Step 5: Handle Special Scenarios

Territory Management

For complex sales territories, use Enterprise Territory Management rather than complicated sharing rules. It's designed for this.

Partner/Customer Communities

External users need different treatment:

• Use External OWD settings (can be more restrictive)
• Leverage Account/Contact relationships
• Implement sharing sets for scalability
• Avoid sharing rules for external users (performance impact)

Large Data Volumes (LDV)

Over 10 million records? Special considerations apply:

• Minimize sharing rules (each one requires calculation)
• Use ownership-based sharing over criteria-based
• Consider data archiving strategies
• Implement selective sharing with custom solutions

Common Pitfalls and How to Avoid Them

1. The "View All Data" Trap

   Never use View All Data as a quick fix. It bypasses all sharing rules and is rarely necessary.

2. Role Hierarchy Sprawl

   Don't create a role for every job title. Consolidate where sharing needs are identical.

3. Sharing Rule Explosion

   If you have 50+ sharing rules, rethink your model. You're probably solving an architecture problem with configuration.

4. Profile Permission Creep

   Profiles accumulate permissions over time. Audit quarterly and move to permission sets.

5. Manual Sharing Chaos

   Manual shares don't transfer with ownership changes. Document and minimize usage.

Security Audit Checklist

Run this audit quarterly:

• ☐ Review all users with View All Data or Modify All Data
• ☐ Check for inactive users with active licenses
• ☐ Audit sharing rules for redundancy
• ☐ Verify OWD settings match current requirements
• ☐ Review role hierarchy for orphaned roles
• ☐ Check permission set assignments for termed employees
• ☐ Validate external user access levels
• ☐ Test record visibility for sample users in each role

// Find users with dangerous permissions
SELECT Id, Name, Profile.Name, 
       IsActive, LastLoginDate
FROM User 
WHERE (Profile.PermissionsViewAllData = true 
   OR Profile.PermissionsModifyAllData = true)
   AND IsActive = true
ORDER BY LastLoginDate DESC

// Find unused permission sets
SELECT Id, Name, 
       (SELECT AssigneeId FROM Assignments)
FROM PermissionSet
WHERE IsCustom = true
   AND Id NOT IN (
       SELECT PermissionSetId 
       FROM PermissionSetAssignment
   )

Implementation Roadmap

1. Week 1: Audit Current State
   • Document existing sharing model
   • Identify security gaps
   • Map user access requirements
2. Week 2: Design Future State
   • Define OWD strategy
   • Design role hierarchy
   • Plan permission set structure
3. Week 3-4: Build in Sandbox
   • Configure OWD settings
   • Create role hierarchy
   • Build permission sets and groups
4. Week 5: Test and Validate
   • Test with sample users
   • Validate access scenarios
   • Performance testing
5. Week 6: Deploy and Monitor
   • Production deployment
   • User training
   • Monitor and adjust

Conclusion

Salesforce's sharing model is complex, but it doesn't have to be complicated. Start with the most restrictive access (Private OWD), then systematically open access through role hierarchy and sharing rules. Use Permission Set Groups for scalable permission management. Audit regularly.

Remember: It's easier to grant access than to revoke it. Start locked down, then open strategically based on actual business needs, not hypothetical scenarios.

The best security model is invisible to users but bulletproof to auditors.