Organization-Wide Defaults and External Sharing Model

Why This Topic Matters

Organization-Wide Defaults (OWDs) are the foundation of the entire Salesforce record-level security model. Every other sharing mechanism in Salesforce (role hierarchy, sharing rules, manual sharing, teams, Apex managed sharing) only ever opens up access beyond what the OWD allows. If you get the OWD wrong, nothing else in the sharing model can fix it. The External Sharing Model extends this idea by letting administrators set a separate, more restrictive baseline for external users such as Experience Cloud (community) users, portal users, and guest users, without having to lock down internal employees at the same time.

On the Advanced Administrator exam, the Advanced Security and Access domain is heavily weighted, and OWD and external sharing questions appear frequently. They are often scenario-based: a business describes who should and should not see certain records, and you must pick the correct combination of OWD settings and additional sharing tools. Understanding the rules of OWDs, the relationship between internal and external defaults, and the behaviour of special objects is essential to scoring well.

What Are Organization-Wide Defaults?

Organization-Wide Defaults define the baseline level of access that users have to records they do not own. They are set per object under Setup > Security > Sharing Settings. The key concept to remember is that the OWD should be set to the most restrictive level required by any user in the organization. You then use the role hierarchy, sharing rules, teams, and manual sharing to grant wider access to the users who need it.

The available OWD access levels are:

Private: Only the record owner, users above the owner in the role hierarchy (if Grant Access Using Hierarchies is enabled), and users granted access through sharing can view or edit the record.

Public Read Only: All users can view and report on records, but only the owner and users above them in the hierarchy (or users granted access via sharing) can edit them.

Public Read/Write: All users can view, edit, and report on all records of that object.

Public Read/Write/Transfer: Available only for Leads and Cases. All users can view, edit, transfer, and report on all records.

Controlled by Parent: Available for objects on the detail side of a master-detail relationship, and for Contacts, Orders, Assets, and Activities. The user's access to the child record is determined by their access to the parent record. When an object is Controlled by Parent, you cannot create sharing rules for it and you cannot share it manually; all sharing flows from the parent.

Public Full Access: Available only for Campaigns. All users can view, edit, transfer, delete, and report on all campaigns.

Price Books have their own unique settings: Use (all users can view and use price books on opportunities), View Only (users can see price books but cannot add them to opportunities unless shared), and No Access (users cannot see or use price books unless shared).

Users object: The OWD for Users controls whether users can see each other's user records. It can be set to Public Read Only or Private. When set to Private, users can only see their own user record and those shared with them through user sharing rules or manual sharing.

Accounts and Contracts share a single OWD setting; the Contract OWD follows the Account OWD. Accounts are also tied closely to Cases, Contacts, and Opportunities through implicit sharing, which is discussed below.

Grant Access Using Hierarchies

Next to each object's OWD setting is a checkbox labelled Grant Access Using Hierarchies. When checked, users higher in the role hierarchy automatically inherit the same access to records as users below them. This checkbox is always enabled and cannot be disabled for standard objects. It can be disabled only for custom objects. Disabling it is useful for sensitive custom objects where managers should not automatically see their subordinates' records. Note that disabling hierarchy access does not affect access granted via sharing rules, manual sharing, or the record owner's own access.

How OWDs Work in Practice

Think of the sharing model as a series of layers:

1. Object permissions (profiles and permission sets) decide whether a user can access the object at all (Create, Read, Edit, Delete, View All, Modify All).
2. Organization-Wide Defaults set the baseline record access for records the user does not own.
3. Role hierarchy opens access upward to managers (when Grant Access Using Hierarchies is enabled).
4. Sharing rules (owner-based or criteria-based) open access to groups of users based on ownership or field values.
5. Manual sharing, teams (Account, Opportunity, Case teams), and Apex managed sharing open access on a record-by-record basis.
6. View All and Modify All permissions on profiles or permission sets, and the View All Data and Modify All Data system permissions, bypass the sharing model entirely.

Because every layer after OWD only adds access, a common exam principle is: if some users should not see certain records, the OWD must be Private (or Public Read Only if they may view but not edit), and the users who need more access receive it via sharing tools.

Implicit Sharing

Salesforce includes built-in sharing behaviours that cannot be turned off. Users who have access to an Account automatically get read access to its related Contacts, Cases, Opportunities, and Contracts (the exact level depends on the OWD of the child object). Conversely, a user who owns or has access to a child record such as a Case or Opportunity gets implicit read access to the parent Account. For external users, implicit sharing gives community or portal users access to the Account they are associated with and the Cases and Contacts related to it, depending on their license. Exam questions sometimes test whether you know that these behaviours exist and that they are automatic.

Changing OWDs and Sharing Recalculation

When you change an OWD, Salesforce runs a sharing recalculation in the background. In large orgs this can take a long time, and you receive an email when it completes. Making an OWD more restrictive (for example from Public Read/Write to Private) removes access and may cause users to lose visibility to records they previously saw; sharing rules and manual shares become important afterwards. Making an OWD less restrictive may make existing sharing rules redundant. If you set an OWD to Public Read/Write, any manual shares that granted Read/Write become unnecessary and are typically removed by Salesforce during recalculation. Best practice is to test OWD changes in a sandbox and plan them during low-usage periods.

What Is the External Sharing Model?

The External Sharing Model allows you to set separate OWDs for external users. Without it, external users would be subject to the same baseline as internal users, forcing you to lock down internal access just to protect data from customers and partners. With it, the Sharing Settings page displays two columns for each supported object: Default Internal Access and Default External Access.

External users include:
- Experience Cloud users (Customer Community, Customer Community Plus, Partner Community, and legacy portal licenses)
- Guest users of Experience Cloud sites (unauthenticated visitors)
- Chatter External users
- Authenticated Website and Service Cloud Portal users

The external sharing model is enabled by default in newer orgs. In older orgs, it is enabled by clicking Enable External Sharing Model on the Sharing Settings page. When it is first enabled, the external default access for each object is set to match the current internal default, so no one immediately loses access; the administrator then tightens the external defaults as required.

Key Rules of the External Sharing Model

Rule 1: External access can never be more permissive than internal access. The external default for an object must be equal to or more restrictive than the internal default. For example, if Internal is Public Read Only, External can be Public Read Only or Private, but never Public Read/Write.

Rule 2: Tightening internal tightens external automatically. If you change the internal default to something more restrictive than the current external default, Salesforce automatically lowers the external default to match so Rule 1 is never violated.

Rule 3: Disabling the model requires matching defaults. You can only disable the external sharing model if the external defaults are identical to the internal defaults for every object. When disabled, external users simply follow the internal OWDs.

Rule 4: Supported objects. External OWDs are available for Accounts (and Contracts), Assets, Campaigns, Cases, Contacts, Individuals, Leads, Opportunities, Orders, Users, and custom objects. Some objects cannot have separate external defaults and follow their internal setting or the parent object.

Rule 5: Guest users are special. Since the Spring and Summer 2020 releases, guest user security has been tightened significantly. Guest users have a Private OWD for all objects that cannot be changed, they do not inherit access through the role hierarchy, and they cannot be given access via standard sharing rules, manual sharing, or teams. The only way to grant guest users record access is through Guest User Sharing Rules, which are criteria-based and read-only. Guest users also cannot own records (record ownership is reassigned to a default owner). Expect exam questions on this.

Rule 6: Sharing rules can target external users. You can create sharing rules whose target is a group containing external users (such as Customer Portal users, Partner Users, or All Customer Portal Users), as well as Share Group settings for high-volume community users who have no roles. High-volume users (Customer Community license) do not use roles or the hierarchy and gain access via sharing sets and share groups rather than conventional sharing rules.

External Users and the Role Hierarchy

Partner Community and Customer Community Plus users have portal roles (Executive, Manager, User) that sit beneath the role of the internal user who owns the partner or customer Account. This means the Account owner and everyone above them in the hierarchy can see records owned by the external users of that Account. Customer Community (high-volume) users do not have roles and rely on sharing sets, which grant access based on a match between the user's Account or Contact and a lookup on the record.

Typical Design Scenarios

Scenario A: Internal sales reps should see all opportunities, but partners should only see opportunities they own. Answer: Internal OWD for Opportunity = Public Read Only (or Read/Write), External OWD = Private.

Scenario B: Customers in the community should only see their own Cases and Cases related to their Account. Answer: External OWD for Case = Private, then rely on implicit sharing and sharing sets to expose Account-related Cases.

Scenario C: A manager must not automatically see subordinates' records on a custom Compensation object. Answer: OWD = Private, uncheck Grant Access Using Hierarchies (possible because it is a custom object).

Scenario D: Website visitors should see published Knowledge articles or product records without logging in. Answer: Guest User Sharing Rules on the relevant object (not standard sharing rules, not OWD changes, since guest OWD is fixed at Private).

Scenario E: Users should not see all other users in lookups and Chatter. Answer: Set the User object OWD to Private and add User sharing rules where needed.

Exam Tips: Answering Questions on Organization-Wide Defaults and External Sharing Model

Tip 1: Always start from the most restrictive requirement. When a scenario says some users should not see records, the OWD must be restrictive (Private or Public Read Only). Never choose a public OWD and then try to hide records, because there is no tool in Salesforce that removes access below the OWD.

Tip 2: Separate object permissions from record access. If the question is about whether a user can access an object at all or can create or delete records, the answer involves profiles or permission sets. If it is about which records a user can see, the answer involves OWD and sharing.

Tip 3: Remember the direction of the external rule. External default must be equal to or more restrictive than internal. Any answer suggesting external users get more access than internal via OWD is wrong.

Tip 4: Know the object-specific OWD values. Public Read/Write/Transfer = Leads and Cases only. Public Full Access = Campaigns only. Use / View Only / No Access = Price Books. Controlled by Parent = Contacts, Orders, Assets, Activities, and master-detail children. Users = Public Read Only or Private. Accounts and Contracts share one setting.

Tip 5: Controlled by Parent means no independent sharing. If an object is Controlled by Parent, you cannot create sharing rules for it or share it manually. If a question asks how to give someone access to a Contact that is Controlled by Parent, the answer is to share the Account.

Tip 6: Grant Access Using Hierarchies can only be unchecked for custom objects. If a scenario involves a standard object and asks about preventing managers from seeing records, the answer cannot be unchecking this box.

Tip 7: Guest users are the exception to almost everything. Guest OWD is locked to Private, guest users cannot be granted access through standard sharing rules, manual sharing, role hierarchy, or teams, and guest user sharing rules provide read-only access. If a scenario mentions unauthenticated or anonymous site visitors, think Guest User Sharing Rules.

Tip 8: Watch for license-driven behaviour. Customer Community (high-volume) users have no roles and use sharing sets and share groups. Partner Community and Customer Community Plus users have roles and can use sharing rules and the hierarchy. The license named in the question often determines the correct sharing mechanism.

Tip 9: Sharing recalculation is a real consideration. If a question mentions a large data volume, performance concerns, or testing before deployment, remember that OWD changes trigger recalculation, can take time, and should be tested in a sandbox first.

Tip 10: View All and Modify All override sharing. If a scenario says a user can see every record despite a Private OWD, look for View All or Modify All on their profile or permission set, or the View All Data / Modify All Data system permissions, before assuming a sharing misconfiguration.

Tip 11: Eliminate answers that use the wrong tool. Common distractors include: using page layouts or field-level security to restrict record visibility (they do not), using validation rules to hide records (they do not), or creating a sharing rule to restrict access (sharing rules only grant access).

Tip 12: Read for the words internal and external. Many questions hinge on recognising that the organization needs two different baselines. Whenever a scenario involves community, partner, portal, or customer users seeing different data than employees, the External Sharing Model is almost certainly part of the correct answer.

Summary

Organization-Wide Defaults establish the most restrictive baseline of record access per object, and all other sharing tools open access upward from that baseline. The External Sharing Model adds a second, independently configurable baseline for external users that must always be equal to or more restrictive than the internal default. Master the available OWD values, the special behaviour of Controlled by Parent, Grant Access Using Hierarchies, implicit sharing, and guest user restrictions, and approach every exam scenario by asking: What is the most restrictive access anyone needs, and which tool opens access from there? With this mental model, OWD and external sharing questions become some of the most predictable on the Advanced Administrator exam.