Org-Wide Default
An Org-Wide Default (OWD) is the baseline access level Salesforce gives every user to records they do not own, set per object.
Definition
An Org-Wide Default (OWD) is the baseline access level Salesforce gives every user to records they do not own, set per object. It answers a simple question: if you are not the owner, and nobody has shared this record with you, can you see it at all? Each object carries its own OWD at one of several levels, from Private (only the owner sees it) up to Public Read/Write (everyone with object access can view and edit it).
OWD is the floor of the Salesforce record-sharing model. Every other access mechanism, including sharing rules, the role hierarchy, manual shares, and teams, can only widen access above that floor. None of them can take access away below it. That makes the OWD on a sensitive object the single most important security decision in an implementation. Set it too open and data leaks; set it too tight and you spend the rest of the project granting access back.
How OWD anchors the whole sharing model
The access levels you can choose
Salesforce defines each level precisely. Private means only the record owner, and users above that owner in the role hierarchy, can view and edit the record. Public Read Only lets all users view and report on records, but only the owner and people above them can edit. Public Read/Write lets all users view and edit every record. Public Read/Write/Transfer adds the ability to transfer ownership, and it exists only for Cases and Leads. Public Full Access adds delete on top, and it exists only for Campaigns. Controlled by Parent ties a child record to its parent: a user can view, edit, or delete the child only if they can do the same on the parent. Contacts and Orders commonly use Controlled by Parent so their access follows the Account. Not every level is offered on every object, and the picklist in Setup only shows the values that apply. You choose a level deliberately per object, because each one sets a different starting point for who sees what before any sharing is layered on.
Internal and external defaults are separate
Each object can carry two org-wide defaults: one for internal users and one for external users. External defaults apply to authenticated users in Experience Cloud sites and legacy portals. Guest users sit outside this entirely; their access is always Private and cannot be changed. The two settings are linked by one rule from Salesforce: the external default must be more restrictive than or equal to the internal default. You cannot give partners Public Read/Write while internal staff sit at Public Read Only. Salesforce recommends setting external defaults to Private for every object unless a business need says otherwise, then opening specific access through sharing rules or sharing sets. Orgs created after Spring 20 default external access to Private on all objects, while older orgs inherited their internal levels. One caution: once you turn on a separate external sharing model, you cannot turn it off again. You can only realign the internal and external levels to match. Treat the external default as the wall protecting internal data from anyone logging in through a community.
Grant Access Using Hierarchies
Alongside each OWD sits a checkbox called Grant Access Using Hierarchies. When it is on, anyone above the record owner in the role hierarchy automatically gets the owner level of access, no matter how tight the OWD is. A sales manager sees every record their team owns because of this, not because of a sharing rule. For standard objects the box is on and locked, so managers always inherit upward. For custom objects you can clear it, which cuts off that automatic upward access. This matters for compliance data. If you hold HR records, compensation figures, or sensitive customer information on a custom object, leaving hierarchy access on means every executive above the owner can read it. Turning it off keeps the data with the owner and whoever you explicitly share it with. You cannot clear the box when the OWD is set to Controlled by Parent, since that level borrows its rules from the parent object instead.
Tightening the default is a heavy operation
Changing an OWD is not like flipping a flag. When you make a default more restrictive, for example from Public Read/Write down to Public Read Only or Private, Salesforce reruns sharing across every existing record of that object. The change only takes effect once that recalculation finishes, and on a large object it runs asynchronously and can take a while. Tightening also strips access that users quietly depended on. Reports, list views, automation, and integrations that assumed broad visibility can suddenly return nothing. The safe path is to map who relies on the current access, build sharing rules and groups that restore exactly that access for the right people, test the whole thing in a sandbox with realistic data, then deploy. Going from Public to Private in production with no preparation is one of the fastest ways to flood the help desk. There is also a hard guardrail: you cannot change certain defaults from private to public when Apex code references sharing entries for that object.
Loosening the default and redundant shares
Moving in the other direction, from Private toward Public, is mechanically simpler but carries its own risk. When you increase the default access, Salesforce runs sharing recalculation to remove access that has become redundant. If a sharing rule or manual share was granting Read to a group, and the new OWD already grants everyone Read, those individual shares no longer add anything and get cleaned up. The recalculation keeps the sharing tables from carrying dead weight. The real danger of loosening is exposure. A record that was visible to a handful of owners can become visible to the entire internal user base in one save. Before widening, confirm that nothing sensitive lives on that object, because once the default is open you cannot use sharing to claw individual records back into privacy. Privacy only comes from a restrictive OWD, never from a sharing rule layered on top of an open one.
Why a restrictive OWD can slow saves
A Private OWD is the foundation of fine-grained security, but it has a cost. When the default is Private, Salesforce has to calculate, for every record, exactly who should see it through sharing rules, groups, hierarchies, and teams. That calculation happens when records are created, updated, or reparented. On a high-volume object with a deep role hierarchy and many overlapping sharing rules, this work adds latency to saves and can produce slow sharing recalculation in very large orgs. Architects size this during design, not after launch. Techniques like keeping the role hierarchy shallow, favoring criteria-based sharing carefully, and using account or territory ownership patterns all help. The trade-off is real: the tighter and more granular your model, the more sharing the platform maintains behind the scenes. For most orgs this is invisible, but at tens of millions of records it becomes an architectural conversation rather than an admin setting.
Designing OWD object by object
There is no single right OWD for an org. Each object gets its own based on how sensitive its data is and who needs to act on it. Accounts and Opportunities are often Public Read Only or Public Read/Write so the sales team has visibility across the business. Cases might be Private so agents only handle their own queue. Custom objects holding HR data, compensation, or compliance records are usually Private with hierarchy access turned off. The discipline is to decide the default first, because it sets the ceiling on privacy that no later sharing can exceed. Document every choice. A new admin can read the data in an org and never infer why Accounts are open and Cases are closed; that logic lives only in the OWD design and the reasoning behind it. Get the floor right per object, then build sharing rules, groups, and team access on top to hand the right access to the right people.
Set an object's Org-Wide Default in Sharing Settings
Org-wide defaults are set in Sharing Settings under Setup. You pick an internal access level (and optionally an external one) for each object. Plan the change before you make it, because tightening triggers a recalculation across every record and can remove access users rely on.
- Open Sharing Settings
In Setup, go to Quick Find and enter Sharing Settings, then open it. This is the single page that lists the org-wide default for every object in one grid.
- Edit the defaults
Click Edit at the top of the Organization-Wide Defaults section. Each object shows a Default Internal Access picklist, and objects with an external model also show Default External Access.
- Choose the level per object
Set each object to the right level, from Private up to Public Read/Write. Keep external access at or below internal access, and set it to Private wherever you can.
- Handle hierarchy access
For a custom object that must stay with its owner, clear Grant Access Using Hierarchies so managers do not inherit access automatically. This box is locked on for standard objects.
- Save and let recalculation run
Save your changes. If you tightened any default, the new access applies only after sharing recalculation finishes, which runs in the background on large objects.
The baseline access internal users get to records they do not own, set per object from Private through Public Read/Write (and Transfer or Full Access where supported).
The baseline for authenticated Experience Cloud and portal users; must be equal to or more restrictive than internal, and is best left Private.
Controls whether users above the owner in the role hierarchy inherit access automatically; clearable only on custom objects not set to Controlled by Parent.
- Tightening a default reruns sharing on every existing record, so the change is not instant and can briefly disrupt access while recalculation completes.
- You cannot make a record private again with sharing rules once the OWD is open. True privacy must come from a restrictive OWD set on the object.
- Once you enable a separate external sharing model you cannot remove it; you can only realign internal and external levels to match.
- Salesforce blocks changing some defaults from private to public when Apex code references that object's sharing rows.
Trust & references
Cross-checked against the following references.
- Organization-Wide Sharing DefaultsSalesforce
- Organization-Wide Default Access SettingsSalesforce
Straight from the source - Salesforce's reference material on Org-Wide Default.
Hands-on resources to go deeper on Org-Wide Default.
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. What is an Org-Wide Default?
Q2. What are the OWD options?
Q3. What's a best practice?
Discussion
Loading discussion…