Organization-Wide Defaults
An Organization-Wide Default (OWD) is the baseline level of access a Salesforce user has to records they do not own.
Definition
An Organization-Wide Default (OWD) is the baseline level of access a Salesforce user has to records they do not own. Each object carries its own OWD, and that setting answers one question: when you did not create the record and nobody shared it with you, what can you do with it? The available levels are Private, Public Read Only, Public Read/Write, Public Read/Write/Transfer (Leads and Cases), Public Full Access (Campaigns), and Controlled by Parent. The full set of object OWDs is the foundation of the org's sharing model.
OWD is the floor, never the ceiling. Every other sharing tool (role hierarchy, sharing rules, manual sharing, teams, Apex sharing) can only widen access above this baseline. None of them can pull access below it. Salesforce states this plainly in its documentation. That one rule shapes the whole design approach: lock objects down to the tightest level the business can tolerate, then open access deliberately for the people who genuinely need it. You configure OWD under Setup, Sharing Settings.
How the sharing floor decides who sees what
The six access levels and what each one means
Private is the most restrictive setting. Only the record owner, users above the owner in the role hierarchy, and anyone granted access through a rule or manual share can see the record. Public Read Only lets every user view the record but only the owner and people above can edit. Public Read/Write lets everyone view and edit, but ownership and transfer stay with the owner. Public Read/Write/Transfer extends that to reassignment, and Salesforce offers it only on Leads and Cases because those objects move between queues and reps constantly. Campaigns have their own top level, Public Full Access, which adds the ability to edit the advanced setup, run reports against the campaign, and share it. Controlled by Parent is the sixth option: a child object inherits the access a user has on the parent, so a record on the child matches the parent record at all times. Picking the right level per object is the single most consequential security decision in an implementation.
Sensible defaults Salesforce ships out of the box
A fresh org does not start blank. Salesforce sets defaults that suit a typical sales team, and knowing them saves you from re-deciding settings that are already reasonable. Account and Contract default to Public Read/Write so that sales, service, and support all see the customer. Contact defaults to Controlled by Parent, inheriting from the Account. Opportunity and Case default to Public Read Only, which lets the team see deals and tickets without letting everyone edit each other's records. Lead defaults to Public Read/Write/Transfer because leads get reassigned often. Campaign defaults to Public Full Access. Price Book uses a special Use setting rather than a normal access level, and Asset is Controlled by Parent. Activity defaults to Controlled by Parent and Calendar to Hide Details. Treat these as starting points, not gospel. A B2C org with strict territory rules will tighten Account to Private; an internal-only org may leave more open. Document any change you make away from the shipped default so the next admin understands the intent.
Internal and external defaults are set separately
Every object has two OWD columns: one for internal users and one for external authenticated users. External users are the partners and customers who log into an Experience Cloud site or a legacy portal. The split exists so you can let employees collaborate openly while keeping site members boxed into their own records. A common pattern is Account internal at Public Read/Write but external at Private, so a partner sees only the accounts shared with them. Salesforce recommends setting external defaults to Private unless the business genuinely needs something looser. The external sharing model turns on automatically in any org where Experience Cloud or portals are enabled, and orgs created after Spring '20 have it on by default. One caution: once the external model is enabled, it cannot be disabled, so plan before you flip it on in an older org. Guest users sit outside this entirely. Their OWD is Private for every object and cannot be changed, which is why public site visibility relies on guest user sharing rules rather than OWD.
Grant Access Using Hierarchies and the role hierarchy
Sitting next to each object's OWD is a checkbox called Grant Access Using Hierarchies. When it is on, a manager automatically inherits access to every record owned by people below them in the role hierarchy. This is how a sales VP sees all of their team's Opportunities without a single sharing rule. For standard objects the checkbox is always on and cannot be turned off. For custom objects you can clear it, which is occasionally needed for compliance cases where a manager must not see a subordinate's records, for example a confidential HR or whistleblower object. Turning it off does not lock the manager out completely; you can still grant them access by other means. It just stops the automatic upward roll-up. Most orgs leave this on, because the role hierarchy is the cleanest way to mirror reporting lines onto data access. Reach for the override only when a specific object has a real reason to break the pattern, and document why.
Tightening or loosening OWD on a live org
Changing OWD on an org with data is not a quiet edit. Loosening access, say Public Read Only to Public Read/Write, takes effect immediately and every user gets the wider access at once. Tightening access, like Public Read/Write down to Private, does not apply until a sharing recalculation finishes running in the background, and Salesforce emails you when it completes. On large data volumes that recalculation can take a while. Before you tighten, find out who currently relies on the broad access and build the sharing rules that will keep them working, then test the whole change in a sandbox. Flipping an object to Private in production with no compensating rules produces a wave of "I lost my records" tickets. There is also a hard guardrail: you cannot change a custom object from Private to Public if Apex code references the sharing entries on that object, because doing so would orphan those sharing rows. Sequence the change so prose and code stay in agreement.
Where OWD sits among the other access controls
OWD only matters once a user already has object permission. Profiles and permission sets decide whether a user can touch an object type at all through Create, Read, Edit, and Delete. If a user has no Read on Cases, OWD on Case is irrelevant to them; they see nothing regardless. OWD then handles record-level access for the objects a user can reach, and field-level security hides individual fields on top of that. Above the OWD floor, the wideners stack up. The role hierarchy rolls access up reporting lines. Owner-based and criteria-based sharing rules open records to groups, roles, or territories. Manual sharing handles one-off grants on a single record. Teams (Account, Opportunity, Case) grant access to named collaborators. Apex managed sharing covers logic too complex for the point-and-click tools. The mental model is a stack: object permission gates entry, OWD sets the floor, and everything else only ever adds. Hold that picture and any sharing puzzle becomes easier to reason about.
Set organization-wide defaults in Sharing Settings
You configure OWD in one place, Sharing Settings, and edit it per object. Decide each object's level from data sensitivity first, then set it. Plan tightening changes around a sandbox test, because they trigger a background recalculation.
- Open Sharing Settings
From Setup, type Sharing Settings in the Quick Find box and select it. The page lists every object with its current internal and external default side by side.
- Edit the Organization-Wide Defaults area
Click Edit in the Organization-Wide Defaults section. Each object row shows a Default Internal Access dropdown and, where external sharing is enabled, a Default External Access dropdown.
- Set each object's access level
Choose the level per object based on sensitivity. Set external access equal to or tighter than internal; Salesforce recommends external Private unless the business needs more. Private cannot be looser than the matching external value.
- Decide Grant Access Using Hierarchies
For custom objects, leave the Grant Access Using Hierarchies box checked unless a compliance case requires managers not to inherit subordinate records. Standard objects keep it on and the box is locked.
- Save and wait for recalculation
Click Save. Loosening applies at once; tightening runs a background sharing recalculation and you get an email when it finishes. Verify access with a few representative users afterward.
The baseline access internal users have to records they do not own, per object. Options range from Private through Public Read/Write/Transfer depending on the object.
The baseline for external authenticated users (Experience Cloud and portal logins). Must be the same as or more restrictive than the internal default. Recommended Private.
Per-object checkbox that rolls record access up the role hierarchy to managers. Always on for standard objects; optional for custom objects.
An access level for detail objects that inherits the user's access from the parent record, keeping child visibility in lockstep with the parent.
- Tightening OWD does not take effect until the background sharing recalculation completes; loosening applies immediately.
- You cannot change a custom object from Private to Public while Apex code references its sharing entries.
- Guest user OWD is Private for all objects and cannot be edited; use guest user sharing rules for public site access instead.
- Once the external sharing model is enabled in an org, it cannot be disabled, so plan before turning it on.
Prefer this walkthrough as its own page? How to Organization-Wide Defaults in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Organization-Wide Defaults.
Hands-on resources to go deeper on Organization-Wide Defaults.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. How does every other sharing mechanism relate to an object's Organization-Wide Default?
Q2. When an admin changes an object's Organization-Wide Default from Public Read/Write to Private, what is the immediate effect on existing records?
Q3. Why do Organization-Wide Defaults provide a separate setting for external Experience Cloud users?
Discussion
Loading discussion…