Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
DictionaryOOrganization-Wide Defaults
AdministrationBeginner

Organization-Wide Defaults

Organization-Wide Defaults (OWD) are the Salesforce baseline access settings that establish minimum visibility for every object in the org.

§ 01

Definition

Organization-Wide Defaults (OWD) are the Salesforce baseline access settings that establish minimum visibility for every object in the org. Each object has its own OWD, set to Private, Public Read Only, Public Read/Write, Public Read/Write/Transfer, or Controlled by Parent. The collection of all object OWDs is the org's sharing model foundation: every other sharing mechanism (sharing rules, manual shares, role hierarchy, team access) builds on top of OWD by widening access, never restricting below it.

OWD is configured under Setup > Security > Sharing Settings. The decision is the most consequential security choice in any Salesforce implementation. A misconfigured OWD on a sensitive object (HR data, customer financial data) exposes records to inappropriate users. Conversely, an over-restrictive OWD on a collaboration-needed object (Account, Opportunity) blocks legitimate access and forces administrators to build extensive sharing rules to compensate. Plan OWD per object based on data sensitivity, user populations, and the access patterns the business genuinely needs.

§ 02

How Organization-Wide Defaults shape access

Per-object OWD design

Each object has independent OWD. Plan deliberately: Account typically Public Read/Write for B2B sales visibility; Opportunity often Private to restrict competitive visibility between reps; HR data Private; product catalogs Public. The design encodes the access model the business needs; document it clearly because the data alone does not explain why.

Internal versus External OWD

Each object has separate OWD for internal users and external (Community/Experience Cloud) users. External OWD is typically Private even when internal is Public; partners and customers should not see records the same way internal users do. This separation is critical for any org using Experience Cloud.

Tightening from Public to Private

Changing OWD from Public to Private restricts access on every existing record. Users currently relying on the broad access lose visibility unless sharing rules compensate. Plan the change: identify the affected user population, build sharing rules in advance, test in sandbox, deploy carefully. Tightening in production without compensation produces a wave of access complaints.

Loosening from Private to Public

Changing OWD from Private to Public exposes records previously restricted. Audit current sharing before loosening: which user populations could see which records, and which should not. The new OWD removes the access restriction; sharing rules cannot retroactively restore privacy.

Role hierarchy interaction

The Grant Access Using Hierarchies option controls whether managers inherit visibility from subordinates. Default on; some compliance scenarios require bypassing this. Configurable per object.

Controlled by Parent

Some objects (Contact, Order) can use Controlled by Parent OWD, inheriting from their parent (Account, etc.). The child object's access matches the parent's at all times. Simplifies the access model for parent-child object pairs where access should mirror.

Performance considerations

Private OWD with extensive sharing rules can produce slow sharing recalculation on high-volume objects. Salesforce calculates sharing on save; complex models add latency. Test on representative data volumes; very large orgs sometimes hit sharing recalculation issues that require architectural changes to address.

§ 03

Set Organization-Wide Defaults

Setting Organization-Wide Defaults is a foundational security decision. The steps below cover the design and rollout for a new org or major access model change.

  1. Classify data sensitivity per object

    For each object, classify data sensitivity. HR, Compensation, sensitive customer financial data: high sensitivity. Product catalog, public reference data: low.

  2. Map user access needs

    For each object, document which user populations need access. The matrix determines whether Public is appropriate or whether Private plus sharing is needed.

  3. Open Sharing Settings

    Setup > Security > Sharing Settings. OWD list shows current settings per object.

  4. Set OWD per object

    Click Edit on Organization-Wide Defaults. For each object, set Internal and External OWD per the design. Save.

  5. Configure Role Hierarchy per object

    For objects where hierarchy should not grant access (compliance scenarios), uncheck Grant Access Using Hierarchies.

  6. Build sharing rules to compensate

    For Private OWDs, build sharing rules for legitimate access needs. Test with sample users from each population.

  7. Document the design

    Capture the OWD per object plus rationale in a doc. The data does not explain why OWD is set the way it is; future admins need the context.

Key options
Privateremember

Only owner sees. Strictest access; default for sensitive objects.

Public Read Onlyremember

Everyone with object Read sees; only owner edits.

Public Read/Writeremember

Everyone with Read/Write sees and edits. Most permissive common setting.

Public Read/Write/Transferremember

Adds transfer ownership.

Controlled by Parentremember

Inherits from parent object. For child objects matching parent access.

Gotchas
  • Tightening OWD restricts access on every existing record. Plan sharing rules to compensate before tightening.
  • Internal and External OWDs are separate settings. Confusion between them produces unexpected Community access.
  • Role hierarchy bypasses OWD by default. Compliance scenarios needing hierarchy bypass require explicit configuration.
  • 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

Official documentation

Straight from the source - Salesforce's reference material on Organization-Wide Defaults.

Was this entry helpful?
Help us write better definitions. Quick reactions or detailed edit suggestions.

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 are Organization-Wide Defaults?

Q2. What are the OWD options?

Q3. What's the recommended approach?

§

Discussion

Loading…

Loading discussion…