Organization-Wide Defaults (OWD) in Salesforce, explained

Org-wide defaults are where every Salesforce sharing decision begins. Get them right and the rest of the model — role hierarchy, sharing rules, shares — has a clean foundation to build on. Get them wrong (usually too open) and no amount of clever sharing rules will fix it. This guide explains what they are and how to set them well.

What org-wide defaults are

Organization-Wide Defaults (OWD) define the baseline level of access users have to records they don’t own, per object. They are the most restrictive setting; everything else exists to open access above this floor.

Org-wide defaults are the floor. Role hierarchy and sharing rules are the ways you raise specific people above it. Nothing standard lets you go below it.

This is why OWD is the first layer in the record access model.

The access levels

Each object’s OWD is set to one of:

Level	Who can see / do what
Private	Only the owner (and users above them in the role hierarchy) can view
Public Read Only	Everyone with object access can view; only the owner can edit
Public Read/Write	Everyone with object access can view and edit
Controlled by Parent	Access follows the related master/parent record

Some objects offer additional variants (e.g. Read/Write/Transfer for leads and cases).

Internal vs external defaults

Many objects let you set separate internal and external org-wide defaults. The external default governs Experience Cloud (community) and portal users and can — and usually should — be more restrictive than the internal one, so external audiences don’t inherit the broader access your staff have.

Best practice: start restrictive, open deliberately

The golden rule:

Set OWD to the most restrictive level the business can tolerate — usually Private — then open access up with the role hierarchy and sharing rules.

The reason is the direction of the sharing model. Access is additive: you can always add access on top of a Private baseline, but you cannot use sharing rules to subtract access an over-open OWD already handed to everyone. Starting Private keeps the model intentional, auditable, and easy to reason about.

A quick way to choose

For each object, ask: should a random employee who doesn’t own this record see it by default?

• No, never → Private.
• They can read but not change it → Public Read Only.
• Anyone can freely edit it → Public Read/Write (rare for sensitive data).

Changing an OWD after go-live

• Opening an OWD (e.g. Private → Public Read Only) is low-risk — it only grants more access.
• Tightening an OWD (Public → Private) is the change to plan. It triggers a sharing recalculation and can remove access users currently depend on. Test in a sandbox, and communicate before you ship.

Why OWD is the first thing to audit

Because every other mechanism builds on it, an over-open OWD silently inflates what everyone can see — and it’s invisible until someone asks “wait, who can see all of these?” When you review access, OWD is the baseline that explains the largest surprises.

AgentForceAccess makes that baseline legible: ask why a user can see a record and it tells you when the answer is simply “the org-wide default is Public” — versus a specific rule or share — so you fix the cause at the right layer.

Frequently asked questions

What does each OWD access level mean?

Private — only the owner and users above them in the role hierarchy can see the record. Public Read Only — everyone with object access can view, only the owner can edit. Public Read/Write — everyone can view and edit. Controlled by Parent — access follows the related master record.

Why should I start with Private?

Because sharing is additive: you can always open access up with role hierarchy and sharing rules, but you cannot use them to claw back access an over-open OWD already granted. Starting Private and widening deliberately keeps the model intentional and auditable.

What are internal vs external org-wide defaults?

Many objects let you set a separate default for external users — Experience Cloud / community and portal users — that can be more restrictive than the internal default. This prevents external audiences from inheriting the access your internal users have.

Can I lower access for one object after going live?

Yes, but tightening an OWD triggers a sharing recalculation and can remove access people currently rely on, so test in a sandbox and communicate the change. Opening an OWD is low-risk; restricting one is the change to plan carefully.