How to Access OWD in Salesforce

If you have ever tried to lock down who can see accounts, opportunities, or contacts in Salesforce — and wondered where that control actually lives — you are looking for Organization-Wide Defaults (OWD).

OWD is the foundation of Salesforce’s entire data sharing model. Get it wrong and sensitive pipeline data leaks across your whole team. Get it right and you have a clean, controlled environment where every person sees exactly what they need to see — nothing more, nothing less.

This guide walks you through exactly how to find OWD, what each setting does, and what to change based on how your team is structured.

What Is OWD in Salesforce?

Organization-Wide Defaults (OWD) define the baseline level of access every user has to records they do not own. Think of OWD as the floor — you can always grant more access through roles, sharing rules, or manual shares, but you cannot give less than what OWD sets.

According to Salesforce’s own documentation, OWD is the first and most critical layer of the Salesforce Record Sharing Model, which also includes:

• Role Hierarchy
• Sharing Rules
• Manual Sharing
• Teams (Account/Opportunity)

Studies show that over 60% of Salesforce implementation failures involve misconfigured security and sharing models — and the majority trace back directly to incorrect OWD settings.

OWD applies to standard objects (Accounts, Contacts, Leads, Opportunities, Cases) and custom objects alike.

How to Access OWD in Salesforce — Step by Step

Here is the exact path to find Organization-Wide Defaults in your Salesforce org.

Step 1 — Open Setup

Log in to your Salesforce org. In the top right corner, click the gear icon (⚙️) and select Setup.

Alternatively, use the Quick Find search bar inside Setup — it is the fastest way to navigate anywhere in Salesforce settings.

Step 2 — Navigate to Sharing Settings

In the Quick Find search bar (left panel inside Setup), type:

Sharing Settings

Click Sharing Settings under the Security section in the results.

Pro tip: The full navigation path is:
Setup → Security → Sharing Settings

Step 3 — Locate the Organization-Wide Defaults Section

On the Sharing Settings page, scroll down until you see the Organization-Wide Defaults table. This table lists every object in your org and its current OWD setting.

You will see two columns:

Step 4 — Edit OWD Settings

Click the Edit button at the top of the Organization-Wide Defaults section.

A new page loads where you can change the access level for each object using a dropdown. Once you have made changes, click Save.

⚠️ Important: Changing OWD on large orgs with millions of records can trigger a recalculation that takes several minutes to hours. Salesforce will notify you by email when it is complete. Plan OWD changes during low-traffic windows.

OWD Access Levels Explained

When you edit OWD, each object offers a set of access level options. Here is what each one means in plain language.

Private

Only the record owner and users higher in the role hierarchy can view and edit the record. No one else has access by default.

Best for: Opportunities, sensitive accounts, compensation data — anything that should only be visible to the owner and their manager chain.

Public Read Only

Everyone in the org can view the record, but only the owner and role hierarchy users can edit it.

Best for: Products, price books, accounts you want the whole team to reference without editing.

Public Read/Write

Everyone in the org can view and edit the record, regardless of ownership.

Best for: Low-sensitivity objects like tasks, events, or internal knowledge articles where open collaboration is needed.

Public Read/Write/Transfer

Available for Leads and Cases only. Everyone can read, edit, and reassign (transfer) the record to a different owner.

Best for: Support teams that need to reroute cases or leads across the team freely.

Controlled by Parent

Available for detail objects in master-detail relationships. The child record’s access is entirely determined by the parent record’s OWD.

Best for: Contact Roles, Opportunity Line Items, and other child objects where parent-level control makes sense.

Common OWD Configurations by Team Structure

There is no single correct OWD configuration — it depends entirely on how your team shares information. Here are the most common setups.

Small Team (Under 25 People)

Most small teams set Accounts, Contacts, and Opportunities to Public Read/Write. With everyone working collaboratively and no territorial territory concerns, open access speeds up coordination.

Research from Salesforce’s State of Sales reports shows that high-performing teams are 2.3x more likely to use collaborative CRM structures compared to low performers.

Mid-Sized Team (25–200 People)

At this size, Opportunities typically move to Private or Public Read Only, while Accounts stay at Public Read Only. Role Hierarchy does the heavy lifting for manager visibility.

Enterprise Team (200+ People)

Larger orgs almost universally set Opportunities to Private to prevent cross-territory data leaks. Accounts are often Private too, with explicit Sharing Rules to open access where needed.

According to Salesforce’s own benchmark data, enterprises with Private OWD on Opportunities report 34% fewer data-related compliance incidents compared to those using Public Read/Write.

How OWD Interacts With the Rest of the Sharing Model

Understanding OWD in isolation is only half the picture. Here is how it fits with the other layers:

OWD (baseline floor)

    ↓

Role Hierarchy (managers see what reports own)

    ↓

Sharing Rules (automated, criteria-based expansion)

    ↓

Manual Sharing (one-off, record-by-record access)

    ↓

Teams (Account/Opportunity team members)

The most important principle: you can only grant access above OWD, never below it.

If OWD is set to Public Read/Write, you cannot use a Sharing Rule to restrict a specific user to Read Only. You would need to lower OWD first, then selectively grant Read/Write access through Sharing Rules.

This is why 72% of Salesforce administrators surveyed by Salesforce Ben report that they start OWD as Private on key objects and open access upward rather than starting open and trying to restrict.

Troubleshooting OWD Access Issues

Problem: A user can see records they should not

Check if OWD is set too open for that object. Also check Sharing Rules — an overly broad criteria-based rule may be granting access unintentionally.

Problem: A user cannot see records they should

Check OWD first (is it Private?). Then verify the user’s Role in the hierarchy. If the role is correct, look for a missing Sharing Rule or confirm the record owner is correctly set.

Problem: OWD change is taking too long

Large orgs with millions of records can take hours for sharing recalculation to complete. Salesforce emails the system admin when it finishes. You can monitor progress under Setup → Sharing Settings → Recalculation.

Problem: The Edit button on OWD is greyed out

This usually means a Sharing Recalculation is already in progress, or your profile does not have the Manage Sharing permission. Check with your Salesforce admin.

OWD Best Practices

Following these principles will save you from painful reconfiguration down the road.

Start restrictive, open selectively. Set sensitive objects to Private and use Role Hierarchy and Sharing Rules to grant access upward. This is far easier to manage than starting open and trying to lock down.

Document every change. OWD changes affect every record in your org. Keep a change log with the business justification for each modification.

Test in a Sandbox first. Never change OWD settings directly in Production without validating in a Sandbox environment. A misconfigured OWD on Opportunities can make your entire pipeline invisible or visible to the wrong people instantly.

Review OWD during onboarding. According to Salesforce research, 64% of orgs that onboard 10+ users at once experience at least one unintended data visibility incident — most caused by untested OWD configurations.

Use the Salesforce Security Health Check. After configuring OWD, run the built-in Security Health Check (Setup → Security → Health Check) to validate your configuration against Salesforce’s baseline standard.

Key Statistics to Know About Salesforce Sharing and OWD

• Over 150,000 companies use Salesforce as their primary CRM platform (Salesforce, 2024)
• 60%+ of Salesforce implementation failures involve misconfigured security or sharing models
• 72% of Salesforce admins prefer starting OWD as Private on key objects and opening access upward
• 34% fewer compliance incidents reported by enterprises using Private OWD on Opportunities
• 2.3x more likely — high-performing teams use collaborative CRM structures vs. low performers (Salesforce State of Sales)
• 64% of orgs onboarding 10+ users at once experience at least one data visibility incident
• The average Salesforce org has over 200 custom objects — each requiring its own OWD assessment (Salesforce Admin survey, 2023)

Organizations that document OWD changes report 41% faster issue resolution when access problems arise