TL;DR: Org-Wide Defaults (OWD) set the baseline visibility for each object. “Controlled by Parent” means child records inherit the parent’s sharing, which causes problems with external users. Use explicit OWD + Sharing Rules when you need granular control.
Introduction
Salesforce security operates in four distinct layers. Most admins focus on the first three—user access, object permissions, and field visibility—and then hit a wall with the fourth: record-level sharing.
This is where things get real. And it’s where most admins get confused. Permissions answer “what type of data can they access?” Sharing answers “which specific records can they access?” It’s the difference between “can Sarah see Accounts?” and “can Sarah see the Acme Corp Account?” This guide walks you through the model that underpins record sharing: Org-Wide Defaults, and shows you how to avoid the pitfalls that trip up experienced admins—especially with external users.
The Four Layers of Salesforce Security
Before diving into sharing, let’s establish the complete picture:
- Org Access — Can they log in at all? (Login Hours, IP Restrictions, Session Settings)
- Object Access — Can they see/edit this type of data? (Profiles, Permission Sets)
- Field Access — Can they see/edit this specific field? (Field-Level Security)
- Record Access — Can they see this specific record? (Org-Wide Defaults, Sharing Rules, Manual Sharing, Role Hierarchy)
Each layer is independent. You can have full CRUD permission on Accounts but still not see a specific Account record if sharing rules block it.
Understanding Org-Wide Defaults (OWD)
What Is OWD?
Org-Wide Defaults set the baseline visibility for each object. They answer a fundamental question: “If I don’t explicitly share a record with someone, can they see it?”
Here’s the critical part: OWD isn’t org-wide—despite the name. You configure it per object (Accounts, Opportunities, Cases, etc.). Each object gets its own default. You decide what that baseline looks like.
The Four OWD Levels
OWD controls visibility for records in relation to ownership:
| OWD Setting | Who Can See | Who Can Edit | Security Level |
|---|---|---|---|
| Private | Only the owner + those explicitly shared the record | Only the owner + those explicitly shared | Most restrictive (most secure) |
| Public Read Only | Everyone in the org | Only the owner | Readable by all, editable by owner |
| Public Read/Write | Everyone in the org | Everyone in the org | Most open (least secure) |
| Controlled by Parent | Same visibility as the parent record | Same as parent, plus CRUD rules | Depends on parent’s OWD |
The Strategic Decision: Closed by Default, or Open?
Here’s the truth most admins learn the hard way: start closed, open up selectively.
If you set everything to Private, you’ll add Sharing Rules to grant access to specific groups. You maintain control. Accidental over-sharing becomes unlikely. If you start with everything Public, you’re betting that admins will manually restrict access. They won’t. People see more than they should, you can’t audit who has what, and closing it down later feels impossible—users are already used to the access.
The trade-off? Private creates friction. Users complain “I can’t see records I need.” You then write a Sharing Rule to fix it. More work upfront, but it’s the right pattern for any new org.
OWD Is Per-Object, Not Org-Wide
This is critical. You don’t set one OWD for the entire org. You set it separately for each object:
Accounts → Private Opportunities → Private Contacts → Public Read Only Cases → Private Leads → Public Read/Write
Each decision is based on:
- Data sensitivity: How confidential is this? (Opportunities = competitive, set Private)
- Collaboration needs: Do teams need to work together on this? (Leads = hot, set Public Read/Write)
- Regulatory requirements: Are there restrictions? (Healthcare/Finance = stricter, set Private)
The Role Hierarchy: Who Sees What Based on Position
OWD is the baseline. The Role Hierarchy is the first exception. It answers: “Can a manager see their reports’ records?”
By default in Salesforce, yes—and this is actually one of the few places where the system works in your favor. Set up a Role Hierarchy (Sales Rep → Sales Manager → Director → VP), and managers automatically see records owned by their direct reports, regardless of OWD. It’s built in. No Sharing Rules needed.
Example: Sarah (Sales Rep) owns Account “Acme Corp” with OWD set to Private. Sarah’s manager, Tom, can see Acme Corp because he’s above Sarah in the Role Hierarchy. A colleague at Sarah’s level (also a Sales Rep) cannot see it.
This is why Role Hierarchy matters: it automatically grants upward visibility. You don’t need to write sharing rules for managers to see their team’s records—it’s built in.
Important: The Role Hierarchy flows only upward. Sarah’s manager can see her records. Sarah cannot see her manager’s records (unless Tom explicitly shares them with her).
Sharing Rules: Automating Access Beyond the Hierarchy
Role Hierarchy handles the org structure. Sharing Rules handle exceptions: “Share these records with this group, even though they don’t own them and aren’t up the chain.”
What a Sharing Rule Does
A Sharing Rule automatically shares records matching certain criteria with a specific user, role, or group:
Rule: “Share Opportunities with Sales Admins” ├─ WHERE: Opportunity.StageName = “Negotiation” ├─ WITH: Role “Sales Admin” └─ ACCESS: Read/Write
Every Opportunity in Negotiation stage is automatically shared with anyone in the Sales Admin role. You don’t have to manually share each one.
When to Use Sharing Rules
Sharing Rules handle repeatable patterns. Use them when you’ve got a group of people who need the same access (all EMEA sales reps seeing EMEA contracts), when the rule’s based on a field value (Account’s Region = “EMEA”), and when that access is ongoing, not a one-off favor. Don’t use Sharing Rules for one-time access—that’s what Manual Sharing is for.
The Gotcha: “Controlled by Parent”
What It Means (Correctly)
“Controlled by Parent” means the child record’s visibility follows the parent record’s actual sharing. If the parent record is shared with you, the child becomes visible.
The Problem: It Cascades Downward
Here’s where admins get blindsided. “Controlled by Parent” doesn’t mean the child follows the parent’s OWD setting. It means the child follows the parent’s actual sharing. If you have access to the parent, the child becomes visible. Simple, right? Except it cascades.
Let me walk you through a real scenario:
Account: “Acme Corp” OWD: Private Owner: Sarah (Sales Rep) Opportunity: “Big Deal” OWD: Controlled by Parent (Account) Owner: Sarah Order: “Order-001” OWD: Controlled by Parent (Opportunity) Owner: Michael (Finance) Question: Can Tom (colleague) see Order-001? Answer: 1. Can Tom see Account “Acme Corp”? NO (Sarah owns it, it’s Private) 2. If Tom can’t see the Account, he can’t see records controlled by it 3. Opportunity is controlled by Account → Tom can’t see it 4. Order is controlled by Opportunity → Tom can’t see it either 5. Result: Tom CANNOT see Order-001 Michael’s ownership doesn’t matter. Visibility doesn’t flow upward from child to parent; it flows downward from parent to child.
This is the core insight: “Controlled by Parent” visibility flows down the hierarchy, not up. If the grandparent is invisible to you, so is everything below it.
The Real Nightmare: External Users
This is where it breaks down catastrophically. I’ve seen admins hit this wall repeatedly. You’re setting up portal access for customers. Everything looks correct. Then the portal user can’t see their own contact record. Why? Because you set Contact OWD to “Controlled by Parent” (Account), and the parent Account is invisible to them.
Account: “Acme Corp” OWD: Private Owner: Sarah (internal) Contact: “John” (Acme employee – portal user) OWD: Controlled by Parent Portal User: John (created from Contact) Question: Can John see his own Contact record? Answer: NO, initially – Account is Private – John doesn’t own it (Sarah does) – Contact is Controlled by Parent (Account) – John has no access to the Account – Therefore: John CANNOT see the Contact (himself!) How to fix: → Use a Sharing Rule: “Share Accounts with portal users who are Contacts on that Account” → Now John can see Acme Corp → Now John can see the Contact record
This is the gotcha admins hit repeatedly: external users own records, but can’t see them because the parent record is invisible to them.
When “Controlled by Parent” Is a Bad Idea
Avoid it when external users need independent access to child records without seeing parents. Avoid it when child records have multiple audiences—some people should see Order records but not Opportunities, or Comments but not the Case. And definitely avoid it with multi-level hierarchies where visibility cascades downward: Grandparent → Parent → Child. If the grandparent’s invisible, the whole chain collapses.
In these cases, use explicit OWD + Sharing Rules instead.
Case Comments: The Exception That Proves the Rule
Here’s a special case. Case Comments have a built-in field: IsPublished (checkbox). This controls visibility to external users:
Case: “Customer complaint” ├─ Comment-1: “Customer says X is broken” │ IsPublished = TRUE │ → Portal user sees it ✓ ├─ Comment-2: “Internally, this is a known issue” │ IsPublished = FALSE │ → Portal user doesn’t see it ✗ └─ Comment-3: “We’re billing them extra for the workaround” IsPublished = FALSE → Portal user doesn’t see it ✗
Important: This is not standard Salesforce security. It’s a feature Salesforce built specifically for Case Comments because the use case (sharing some comments with customers, hiding others) was so common.
Other objects don’t have this. EmailMessage doesn’t. Opportunities don’t. You have to design sharing logic for them manually.
Decision Framework: When to Use Each Approach
Designing OWD for an object? ├─ Is the child record always relevant in the parent context? │ ├─ YES → Consider “Controlled by Parent” │ └─ NO → Use explicit OWD + Sharing Rules │ ├─ Are there external users who should see the parent but NOT all children? │ ├─ YES → Avoid “Controlled by Parent”; use explicit sharing rules │ └─ NO → “Controlled by Parent” works fine │ ├─ Is there a cascading hierarchy (grandparent → parent → child)? │ ├─ YES → Be very careful; visibility compounds downward │ └─ NO → Safer to use “Controlled by Parent” │ └─ Does this object have built-in “internal/external” controls? ├─ YES (like Case Comments’ IsPublished) │ → Use those controls + explicit OWD, not “Controlled by Parent” └─ NO → You’re responsible for sharing logic
Template for Designing OWD in a New Org
Step 1: Audit Your Objects
List every object that will store business data. Ask three questions for each:
| Object | Data Sensitivity | Collaboration Needs | Recommended OWD |
|---|---|---|---|
| Accounts | Medium-High (competitive) | Team must collaborate | Private (open via Sharing Rules) |
| Opportunities | High (revenue-sensitive) | Managers need to see team’s deals | Private (Role Hierarchy handles managers) |
| Contacts | Low-Medium | Often need cross-team visibility | Public Read Only |
| Cases | Medium (customer-sensitive) | Support owns cases, but managers need visibility | Private (Role Hierarchy + Sharing Rules) |
| Knowledge | Low (reference material) | Everyone reads, no one edits | Public Read Only |
Step 2: Identify Child Objects
For each child object (Contacts under Accounts, Opportunities under Accounts, Tasks under Cases), ask: Can it exist independently, or is it always tied to the parent? Do child records always share the parent’s audience? Will external users access this object?
Example: EmailMessage (child of Case). Can’t exist independently—it’s always tied to a Case. Same audience as parent? No. Some emails are internal-only, some are customer-visible. External users? Yes, portal users. Decision: Don’t use “Controlled by Parent.” Use explicit OWD (Private) + Sharing Rules to share specific emails.
Step 3: Plan Your Sharing Rules
For each object, identify the exceptions to OWD. You might have regional requirements (all EMEA users seeing EMEA contracts), role-based rules (Support Managers seeing their team’s cases), external user access (portal users seeing Accounts they’re Contacts on), or cross-functional sharing (Finance seeing high-value Opportunities). Write those down. That’s your Sharing Rules roadmap.
Pro tip for migrating from other CRMs: When onboarding users from Salesforce competitors (HubSpot, Pipedrive, custom CRM), they often come with expectations about how sharing should work. Clarify upfront: “In Salesforce, the baseline is [OWD setting]. We’ll share [specific records] with [specific groups] via Sharing Rules.” This prevents post-launch complaints.
Common Mistakes and How to Avoid Them
Mistake 1: Starting “Open,” Then Trying to Close Down
What happens: Set OWD to Public Read/Write to avoid friction. Users complain about seeing too much. Try to add restrictions. Too late—you’re fighting muscle memory and entrenched habits.
Fix: Start Private. Write one Sharing Rule upfront (e.g., “Share Accounts with Sales team”). Users have the access they need from day one, and the boundary is clear.
Mistake 2: Using “Controlled by Parent” With External Users
What happens: Set Contact OWD to “Controlled by Parent” (Account). Portal user John creates a contact. John can’t see his own contact because the parent Account is invisible to him.
Fix: Use explicit OWD + Sharing Rules. Set Contact OWD to Private. Add a Sharing Rule: “Share Contacts with portal users who own the related Account.”
Mistake 3: Not Thinking About Multi-Level Hierarchies
What happens: Set Order OWD to “Controlled by Parent” (Opportunity). Set Opportunity OWD to “Controlled by Parent” (Account). Customer portal user owns the Account but can’t see Orders because the middle layer (Opportunity, owned by internal sales rep) is invisible to them.
Fix: Break the cascade. Set Order OWD to Private. Add explicit Sharing Rules for who should see Orders.
Mistake 4: Forgetting About Role Hierarchy Implications
What happens: Set Opportunity OWD to Private. Expect managers to use Sharing Rules to see team opportunities. Forget that Role Hierarchy grants managers visibility automatically.
Fix: This is actually not a mistake—it’s the correct behavior. Recognize that Role Hierarchy is your friend. Use it. Don’t override it with Sharing Rules unless you have a specific exception.
Next Steps: Sharing Rules, Manual Sharing, and Role Hierarchy
This article covered the foundation: Org-Wide Defaults and the “Controlled by Parent” gotcha. But OWD is just the baseline. You’ll eventually need to understand Sharing Rules (how to automatically share records based on field values or group membership), Manual Sharing (granting one-off access), Role Hierarchy in depth (leveraging it without over-complicating it), and Apex Managed Sharing (for complex programmatic logic). Once you have OWD configured correctly for your org, those pieces fall into place naturally.
Key Takeaways
OWD is per-object, not org-wide. Each object gets its own baseline visibility setting—Accounts might be Private, Contacts might be Public Read Only. Start closed, open up selectively. Private OWD + targeted Sharing Rules is the right pattern for a new org because it gives you control. “Controlled by Parent” visibility flows downward. If the parent’s invisible to you, so are all children—this is the cascading gotcha that trips admins. “Controlled by Parent” breaks with external users. Use explicit OWD + Sharing Rules instead when portal users or community members are involved. Role Hierarchy is your first exception to OWD. Managers see their reports’ records automatically, regardless of OWD—this one actually works in your favor. And finally, recognize which objects have special sharing logic. Case Comments have IsPublished; EmailMessage doesn’t. Design accordingly.
Author’s note: This guide is designed for admins setting up new orgs or migrating from other CRMs. The sharing model doesn’t change, but the strategic decisions—especially around external users and multi-level hierarchies—often trip up experienced admins. Focus on the decision framework, and the specific Sharing Rules and Manual Sharing patterns will come naturally.