TECH **Salesforce Organization-Wide Defaults (OWD) & Sharing Models: Zero-Fluff, Hands-On Guide**

Salesforce Organization-Wide Defaults (OWD) & Sharing Models: Zero-Fluff, Hands-On Guide

For Admins Who Need to Lock Down (or Open Up) Data—Fast

1. What This Is & Why It Matters

Organization-Wide Defaults (OWD) are the foundation of your Salesforce security model. They define the baseline level of access users have to records they don’t own. Think of OWD like the default lock on a filing cabinet: - Private: Only the owner (and admins) can see the file.
- Public Read Only: Everyone can see the file, but only the owner can edit it.
- Public Read/Write: Everyone can see and edit the file (use with extreme caution).

Sharing Models (Sharing Rules, Manual Sharing, Role Hierarchy, Teams, etc.) are the exceptions to OWD—they let you selectively grant more access than the default.

Why This Matters in Production

• Security Nightmare: If OWD is too open (e.g., Public Read/Write on Opportunities), sales reps can accidentally (or maliciously) edit each other’s deals. This leads to data corruption, compliance violations (GDPR, HIPAA), and angry executives.
• User Frustration: If OWD is too restrictive (e.g., Private on Accounts with no sharing rules), sales teams can’t collaborate, and deals stall.
• Audit Failures: Many compliance frameworks (SOC 2, ISO 27001) require least-privilege access. OWD is your first line of defense.

Real-World Scenario: You inherit a Salesforce org where all objects are set to Public Read/Write. A disgruntled employee exports the entire Contact database and leaks it to a competitor. Your job: Lock it down without breaking critical workflows (e.g., sales teams sharing leads).

2. Core Concepts & Components

3. Step-by-Step: Locking Down an Object (Example: Opportunities)

Goal: Change Opportunities from Public Read/Write to Private without breaking sales workflows.

Prerequisites

• System Administrator profile.
• A sandbox (never test in production!).
• A backup of your sharing settings (use Salesforce Data Loader to export OpportunityShare records).

Steps

1. Check Current OWD Settings

• Go to Setup → Sharing Settings (in the Quick Find box).
• Under Organization-Wide Defaults, find Opportunity.
• Note the current setting (likely Public Read/Write).

2. Change OWD to Private

• Click Edit.
• For Opportunity, select Private.
• Click Save.
• ⚠️ Salesforce will warn you: "This change may take time to process." For large orgs, this can take hours.

3. Verify Access (Before Fixing Breaks)

• Log in as a non-admin user (e.g., a sales rep).
• Try to view/edit an Opportunity they don’t own.
• Expected: They can’t see it (unless they’re above the owner in the role hierarchy).
• Check critical workflows:
• Can sales reps still see Opportunities in reports?
• Can they still convert Leads to Opportunities?
• Do Opportunity triggers/flows still work?

4. Fix Broken Access with Sharing Rules

Problem: Sales reps can’t see each other’s Opportunities anymore.
Solution: Create a sharing rule to grant read-only access to the same team.

• Go to Setup → Sharing Settings.
• Under Sharing Rules, click New for Opportunity.
• Rule Name: Sales Team Read-Only Access
• Rule Type: Based on record owner
• Select which records to be shared: Owned by members of → Role: Sales Team
• Share with: Role: Sales Team
• Access Level: Read Only
• Click Save.

5. Test Again

• Log in as a sales rep.
• Verify they can now see (but not edit) other reps’ Opportunities.
• Check reports/dashboards—data should still appear.

6. (Optional) Add Manual Sharing for Exceptions

Problem: A sales rep needs to edit a specific Opportunity they don’t own.
Solution: Use Manual Sharing.

• Open the Opportunity record.
• Click Sharing (if not visible, add it to the page layout).
• Click Add.
• Search for the user/team to share with.
• Set Access Level: Read/Write.
• Click Save.

7. Document the Change

• Update your data dictionary or security runbook:
• OWD for Opportunities: Private
• Sharing Rules: Sales Team Read-Only Access
• Manual Sharing: Allowed for exceptions (document approval process).

4. ? Production-Ready Best Practices

Security

• Least Privilege: Start with Private for all objects, then open up only what’s needed.
• Audit OWD Quarterly: Use Salesforce Optimizer to flag overly permissive settings.
• Use Controlled by Parent for Hierarchical Data: E.g., Contacts → Accounts, Opportunities → Accounts.
• Restrict Public Read/Write: Only use for objects where everyone truly needs edit access (e.g., Campaigns).

Cost Optimization

• Sharing Rules vs. Teams: Teams are cheaper (no sharing recalculation) but require user training.
• Avoid Over-Sharing: Every sharing rule increases data storage and slows down performance.

Reliability & Maintainability

• Naming Conventions for Sharing Rules:
• SR_Opp_SalesTeam_ReadOnly
• SR_Account_EMEA_ReadWrite
• Test in Sandbox First: Changing OWD can break integrations (e.g., Marketing Cloud, CPQ).
• Use Permission Sets for Exceptions: Instead of opening OWD, grant access via Permission Sets.

Observability

• Monitor Sharing Recalculation: If OWD changes take too long, check Setup → Sharing Settings → View Status.
• Log Manual Sharing: Use Field History Tracking on OpportunityShare to audit who shared what.

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus

Typical Question Patterns

1. "What’s the most restrictive OWD setting?"
2. ✅ Answer: Private.

3. ❌ Trap: Public Read Only (still allows viewing).

4. "A sales rep can’t see an Opportunity they don’t own. What’s the most likely cause?"

5. ✅ Answer: OWD is set to Private and no sharing rules exist.

6. ❌ Trap: "The role hierarchy is broken" (role hierarchy only extends access, not restricts it).

7. "Which OWD setting allows all users to edit records but not transfer ownership?"

8. ✅ Answer: Public Read/Write.

9. ❌ Trap: Public Read/Write/Transfer (allows ownership changes).

10. "When should you use Controlled by Parent?"

11. ✅ Answer: For child objects (e.g., Contacts → Accounts).
12. ❌ Trap: "For top-level objects like Accounts" (they can’t be controlled by a parent).

Key ⚠️ Trap Distinctions

7. ? Hands-On Challenge

Scenario: Your org has Accounts set to Public Read/Write. A compliance audit requires you to change it to Private without breaking the following: - Sales reps must still see Accounts in their region.
- Support agents must see Accounts with open Cases.

Your Task: 1. Change OWD for Accounts to Private.
2. Create sharing rules to maintain the required access.

Solution: 1. Change OWD:
- Setup → Sharing Settings → Edit → Set Account to Private → Save.
2. Create Sharing Rules:
- Rule 1 (Sales by Region):
- Name: SR_Account_Sales_Region
- Share records owned by: Role: [Region] Sales Team
- With: Role: [Region] Sales Team
- Access: Read Only
- Rule 2 (Support for Open Cases):
- Name: SR_Account_Support_OpenCases
- Share records with: Open Cases
- With: Role: Support Team
- Access: Read Only

Why It Works: - OWD Private locks down all Accounts by default.
- Sharing rules selectively grant access to the right teams.

8. ? Rapid-Reference Crib Sheet

9. ? Where to Go Next

1. Salesforce Sharing & Visibility Documentation – Official guide.
2. Trailhead: Data Security – Hands-on modules.
3. Salesforce Optimizer – Free tool to audit security settings.
4. Sharing & Visibility Designer Certification Guide – For advanced admins.