Org-Wide Default
An Org-Wide Default (OWD) is the Salesforce baseline access level for every object, defining the minimum visibility any user has to any record they do not own.
Definition
An Org-Wide Default (OWD) is the Salesforce baseline access level for every object, defining the minimum visibility any user has to any record they do not own. Each object has an OWD setting at one of several levels: Private (only the owner sees), Public Read Only (everyone sees but only owner edits), Public Read/Write (everyone sees and edits), Public Read/Write/Transfer (everyone can also transfer ownership), or Controlled by Parent (inherits from a parent object). OWD is the foundation of the Salesforce sharing model; other mechanisms (sharing rules, manual shares, team access) can only widen access from the OWD baseline, never restrict.
OWD is the single most consequential security decision in any Salesforce implementation. A Public Read/Write OWD on Account means every user with object access to Account sees every Account in the org. Tightening from Public to Private retroactively restricts access on every existing record, which can break downstream automation, reports, and integrations that assumed broad visibility. Loosening from Private to Public exposes data that was previously restricted. Plan OWD changes deliberately and test extensively before applying in production.
How Org-Wide Defaults shape sharing
The five OWD levels
Private: only the record owner (and their hierarchy and explicit shares) see the record. Public Read Only: every user with object Read can view, only owner can edit. Public Read/Write: every user with Read/Write can view and edit. Public Read/Write/Transfer: adds transfer ownership capability. Controlled by Parent: inherits the OWD of a parent object (Account Contact inherits from Account). Each level is per object and per internal/external user separately.
Internal versus external OWD
Each object has separate OWD for internal users and external users (Community/Experience Cloud). The external OWD is typically more restrictive, often Private, even if internal is Public. This separation is critical when Communities expose data; the external OWD prevents partners or customers from seeing internal records inappropriately.
OWD as the floor
OWD sets the minimum access; sharing rules, manual shares, queues, and team access can grant additional access on top. The model is widening, not restricting: no mechanism reduces access below OWD. If OWD is Public Read, sharing rules cannot make a record private to a specific user. Plan accordingly; tighten OWD if true privacy is needed.
Role hierarchy and OWD
The Grant Access Using Hierarchies option controls whether managers automatically see their subordinates' records. Default on for most objects; users above the owner in the role hierarchy see the owned records regardless of OWD. Turning this off requires explicit configuration; some compliance scenarios (HR data, sensitive customer info) require hierarchy-bypass.
Tightening OWD safely
Changing OWD from Public to Private affects every existing record. Sharing rules and manual shares may need to be added to compensate. Plan: identify which users currently rely on the broad access, build sharing rules to restore their access, test in sandbox, deploy carefully. Tightening in production without preparation breaks user workflows.
Performance implications
Private OWD on a high-volume object plus extensive sharing rules can produce slow sharing recalculation when records are created or updated. Salesforce calculates sharing on save; complex sharing models add latency. Test save performance during OWD design; very large orgs with private OWDs sometimes hit sharing recalculation issues that require architectural changes.
Per-object OWD design
Each object can have a different OWD. Accounts often Public for sales visibility, while sensitive objects (HR, Compensation) are Private. Plan OWD per object based on data sensitivity and business need. Document the OWD design; new admins inherit a fundamental access model from the OWD that they cannot infer from the data alone.
Set OWD per object
Setting OWD is one of the most consequential security decisions. The steps below cover the design and rollout process.
- Document per-object data sensitivity
For each object, classify data sensitivity. High sensitivity (HR, Compensation, sensitive customer data) typically needs Private; low sensitivity can be Public.
- Map user access needs
For each object, list which user populations need access. The matrix determines whether Public is appropriate or whether Private plus sharing rules is needed.
- Open Sharing Settings
Setup > Security > Sharing Settings. The OWD section lists current settings per object.
- Set OWD per object
Click Edit. For each object, set Internal and External OWD. Save.
- Configure Role Hierarchy access
For objects where hierarchy should not grant access (compliance scenarios), uncheck Grant Access Using Hierarchies.
- Build sharing rules to compensate
For Private OWDs, build sharing rules to grant access where needed. Test the access pattern with sample users.
- Document the design
Capture the OWD design in a doc. New admins need this context; the data alone does not explain why OWD is set the way it is.
Only owner (and hierarchy) sees. Strictest access.
Everyone with object Read sees; only owner edits.
Everyone with object Read/Write sees and edits.
Adds transfer ownership.
Inherits from a parent object.
- Tightening OWD restricts access on every existing record. Plan sharing rules to compensate before tightening.
- Internal and external OWDs are separate. External default Private even if internal is Public; Communities need careful design.
- Role hierarchy bypasses OWD by default. Compliance scenarios may need to disable this per object.
- Private OWD plus many sharing rules can slow saves. Performance test on high-volume objects.
- Loosening OWD exposes previously restricted data. Audit before changing from Private to Public.
Trust & references
Straight from the source - Salesforce's reference material on Org-Wide Default.
- External Organization-Wide Defaults OverviewSalesforce Help
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…