The three core Organization-Wide Default (OWD) settings differ in how much access a user gets to records they don’t own. Private restricts access to the owner (and people above in the hierarchy, if enabled). Public Read Only lets all internal users view any record but only the owner can edit. Public Read/Write lets all internal users view and edit any record. The owner — regardless of OWD — always retains transfer and delete rights.
Side-by-side comparison
| Capability | Private | Public Read Only | Public Read/Write |
|---|---|---|---|
| Non-owner can view a record | No (unless above in hierarchy or shared) | Yes | Yes |
| Non-owner can edit a record | No | No | Yes |
| Non-owner can transfer/delete a record | No | No | No (still owner-only) |
| Owner can view, edit, transfer, delete | Yes | Yes | Yes |
| Role hierarchy grants extra access | Yes (managers see reports’ records) | Yes — but they already can read, so this enables edit | Already at max for read/edit |
| Manual sharing useful? | Yes — common way to open up | Yes — to grant edit | No — everyone already has read/write |
| Sharing rules useful? | Yes | Yes (only to grant edit) | No |
| Reports show non-owned records? | No (unless visible via hierarchy/sharing) | Yes | Yes |
Why the middle option exists
Public Read Only is the most commonly missed setting. Candidates often assume access is binary — locked or open — but Read Only is the sweet spot for reference data: information everyone in the org needs to see but only specific people (typically the data steward who owns the record) should change.
Classic Public Read Only use cases:
- Accounts in many orgs — anyone can view a customer record, but only the assigned account exec can edit it.
- Products and Price Books in B2B orgs.
- Custom configuration objects that drive flows or pricing — operations team edits, everyone else reads.
When to choose each
- Private — sensitive data where need-to-know is the default. Opportunities (financial), HR data, support cases at some companies, custom objects holding PII.
- Public Read Only — reference data with central stewardship. The right default for most account-style records.
- Public Read/Write — highly collaborative or low-sensitivity data. Many orgs use this for internal-facing custom objects, system configuration objects that don’t need protection, and contact records when reps share contacts freely.
A common mistake is starting with Public Read/Write because “we’ll tighten later.” Tightening OWD on a populated object triggers sharing recalculation, which on a large org can take hours and impacts every downstream sharing rule. Start restrictive and open up — it’s much easier than the reverse.
The two cousins: Public Read/Write/Transfer and Public Full Access
Two objects extend the OWD options beyond the standard three:
- Lead and Case support Public Read/Write/Transfer — anyone can not only edit but also reassign ownership. This is designed for high-throughput lead pools and case queues.
- Campaign supports Public Full Access — read, write, transfer, and delete by anyone. Marketing teams routinely need to co-own campaigns.
These aren’t options on every object — they appear only where Salesforce considers them safe defaults.
What doesn’t change with OWD
OWD only controls record-level visibility and edit rights. It does not affect:
- Object access (CRUD) — that’s the profile/permission set.
- Field-level security — also profile/permission set.
- The owner’s ability to transfer or delete — owners always retain those rights.
- View All / Modify All permissions — these explicitly bypass OWD.
Interviewers like to confirm you understand the boundary: OWD answers “whose records can I see?” — not “can I open this object?” and not “which fields can I read?”
Verified against: Salesforce Help — Organization-Wide Sharing Defaults and the Sharing & Visibility Architect resources. Last reviewed 2026-05-17.