Setting OWD to Public Read/Write Because Sharing Was 'Too Complicated'
“When everyone can see everything, your data model is a liability.”
What Happened
Client said sharing rules were confusing, so they set every object to Public Read/Write. Sales reps could see and edit each other's pipeline. A disgruntled rep exported the entire customer list before quitting. A manager accidentally mass-updated another team's Opportunities. When they finally needed to restrict access for a compliance audit, we had to redesign their entire sharing model under pressure — role hierarchy, sharing rules, teams — while the auditor waited.
The Wrong Way
Organization-Wide Defaults: Account: Public Read/Write Contact: Controlled by Parent Opportunity: Public Read/Write ← EVERYONE can edit EVERY deal Case: Public Read/Write Custom_Financial_Data__c: Public Read/Write ← compliance nightmare Sharing Rules: None needed! Everyone sees everything! Role Hierarchy: Flat (one role) // "It's simpler this way" — famous last words
The Right Way
Organization-Wide Defaults (start restrictive, open up as needed):
Account: Private
Contact: Controlled by Parent
Opportunity: Private
Case: Private
Custom_Financial_Data__c: Private
Role Hierarchy:
CEO
→ VP Sales
→ Sales Manager East → Sales Rep East (x5)
→ Sales Manager West → Sales Rep West (x5)
Sharing Rules (criteria-based):
→ "Regional Account Sharing": Share Accounts where Region = user's region (Read Only)
→ "Manager Pipeline View": Share all Opps with Manager role (Read Only)
// Use Territory Management for complex sales orgs
// Use Teams for exception-based sharing
// Use Restriction Rules to hide sensitive fields even on shared recordsThe Lesson
Start with Private OWD and open up with sharing rules, role hierarchy, and teams. Never start with Public Read/Write — restricting access later is ten times harder than granting it.
Enjoyed this? Get more like it.
Glen's Musings — AI, investing, and building things. Occasional. Free.
More Admin Mistakes
Validation Rules That Block Your Own Automations
Your validation rule doesn't care if a Flow or trigger made the change.
Read moreCareer-EndingCreating an Infinite Loop with Record-Triggered Flows
Flow updates record. Update triggers Flow. Flow updates record. Repeat until Salesforce gives up.
Read moreAnnoyingManaging Access with Profiles Instead of Permission Sets
Profiles are for login settings. Permission Sets are for everything else.
Read more