How Locked Each File Cabinet Starts

Module 2 of 7 in the chapter Org-Wide Defaults, Ownership and the Role Hierarchy, chapter 6 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: For each object, how locked should its records start, for your own people and for people from outside, and what happens when you change your mind?

The org-wide default is way 1 on the map, and it’s where every object starts. Before a single rule, team or line of code, you decide how locked the file cabinet is. Chapter 5 gave you the three choices and the question I ask my clients. This module takes them apart: what each level really allows, the objects that play by their own rules, the second default for people from outside, and what happens when you change one.

Your very first stop

If you’re doing any kind of record-level design in Salesforce, go to Setup, then Sharing Settings. This is your very first stop on the road. At the top is the Organization-Wide Defaults list: every object, with its Default Internal Access, its Default External Access, and a checkbox, Grant Access Using Hierarchies.

And here’s the question you ask for every object on that list. Is there even a single user in your system you need to hide a record from? Even one human being? If yes, you’re probably going to dial it down to Private. Salesforce’s architects say the same: you “lock your data to the most restrictive level,” then “selectively give access to other users” (Platform Sharing Architecture (opens in a new tab), Salesforce Architects, checked 2026-11-07).

Why start locked? Because it’s easier to open up later than to lock down later. Every other way on the map opens records up from the default. If you start open, then find the one person who mustn’t see, you’re redesigning.

And ask it about the future, not only today. Set the org-wide defaults for the most restrictive security you can see coming. Are you planning an Experience Cloud site next year? Watch your external visibility. Watch the attachments and the child records in a master-detail. Everything under a record starts from that record’s default.

Three levels, precisely

Salesforce lets you choose “Controlled by Parent, Private, Public Read Only, or Public Read/Write” for most objects (Organization-Wide Default Access Settings (opens in a new tab), Salesforce Help, checked 2026-11-07). Controlled by Parent comes in the next section. Here are the other three, from locked to open.

Private. “Only users who are granted access by ownership, permissions, role hierarchy, manual sharing, or sharing rules can access the records” (Set Your Internal Organization-Wide Sharing Defaults (opens in a new tab), Salesforce Help, checked 2026-11-07). Out of the box, that’s the owner and the people above the owner in the role hierarchy. Everyone else needs one of the other ways.

Public Read Only. “All users can view and report on records but not edit them. Only the owner, and users above that role in the hierarchy, can edit those records” (Organization-Wide Default Access Settings). Everyone reads; editing still needs a grant.

Public Read/Write. “All users can view, edit, and report on all records.” There’s one thing it doesn’t give away: only the owner can “alter the sharing settings or delete” the record (same page). So even wide open, ownership still matters.

Click to enlarge

One word to watch: “all users”. It means all users who can get into the office. Public Read/Write doesn’t give anyone the object. Without Read on the object from a profile or permission set, the user sees nothing, whatever the default says. The most restrictive wins, as module 1 showed.

Watch it lock

I like to show this live. I take a custom object, call it Runway, where I’ve loaded runways for airports, and switch it from public to Private. That kicks off a sharing recalculation, and after a moment the object is marked Private.

Then I give a pilot and a manager a permission set with Read on Runway and its fields. Both log in. Both can open the Runway tab. And both see no records at all. They’re in the office, the cabinet is locked, and nobody has given them a key yet. That’s Private doing exactly its job. Module 3 hands the pilot a key by making the pilot the owner, and module 4 shows the manager getting one through the hierarchy.

The special objects

Now, there’s an important idea I want you to get. The standard objects linked to the account are special. They’re special. They live in their own world, with their own rules, so don’t try to sort them the same way as the others. My advice: start by learning custom objects, where the choices are simple, and go from there.

Here’s what makes them special. Salesforce lists the other levels, “available for only specific objects” (Organization-Wide Default Access Settings):

Controlled by Parent. For contacts and orders, a user can do something to the record “based on whether he or she can perform that same action on the record associated with it.” If you can see the account, you can see these children. It’s also the setting for the detail side of a master-detail relationship, which module 6 takes apart.
Public Read/Write/Transfer. Everyone can also change the owner. “Only available for cases or leads.”
Public Full Access. Everyone can also delete. “Only available for campaigns.”
Price books have their own levels: Use, View Only and No Access.
Activities are Private or Controlled by Parent. Even when they’re Private, “users with read access to the record to which the activity is associated can view and report on the activity.”
Users are Private or Public Read Only. That’s module 7.

And some objects tie together. “If the default access for Account is set to Private, the default access for Opportunity and Case must be set to Private as well. The default access for Contact must be set to Private or Controlled by Parent” (Set Your Internal Organization-Wide Sharing Defaults). So you can’t lock the account and leave its opportunities open. The family moves together.

A few more you can’t choose freely (same page):

When a custom object is on the detail side of a master-detail relationship with a standard object, its default “is set to Controlled by Parent and it’s not editable.”
Documents, reports and dashboards don’t use org-wide defaults: access follows “the folder in which it’s stored.”
Set products to anything other than Public Read/Write while you use custom code or a package, and “unexpected behavior can occur.”

Two defaults: your people, and people from outside

Every object has two defaults, not one. External org-wide defaults “provide separate organization-wide defaults for internal and external authenticated users” (External Organization-Wide Defaults Overview (opens in a new tab), Salesforce Help, checked 2026-11-07). External means Experience Cloud site users, partner users, customer users and the other outside licenses: people who log in, but who don’t work for you.

Salesforce’s own example is the one I’d give: your employees may all read every account, but your partners mustn’t. So “set the default internal access to Public Read Only and the default external access to Private,” and open records up for external users later “using other features” (same page). Part 3 covers those features.

Three rules come with it (same page):

External can never be more open than internal. “The external access level for an object can’t be more permissive than the internal access level.”
Not every object has one. Salesforce lists accounts, assets, cases, campaigns, contacts, individuals, leads, opportunities, orders, users and custom objects, and says your org “might have other objects.” For one without it, set the default to Private and share with all internal users through a sharing rule.
Guests have no dial. “Guest users aren’t considered external users. Guest users’ org-wide defaults are set to Private for all objects, and this access level can’t be changed.”

And one more, when Controlled by Parent is involved: “The default internal and external access must match if either one is set to Controlled by Parent” (Set Your Internal Organization-Wide Sharing Defaults).

Click to enlarge

There’s a performance reason too. Salesforce says external defaults “simplify your sharing rules configuration and improve recalculation performance,” and speed up “reports, list views, searches, and API queries” (External Organization-Wide Defaults Overview). Without it, you’d set the object Private for everyone and then write rules to open it back up for every employee.

Changing a default

Remember module 1: Salesforce works out access when the setup changes. An org-wide default is the biggest setup change there is, because it touches every record of the object. “When you update organization-wide defaults, sharing recalculation applies the access changes to your records. If you have a lot of data, the update can take longer” (Set Your Internal Organization-Wide Sharing Defaults). You get an email when it’s done, and you can follow it on the Background Jobs page.

Which way you go matters (same page):

Opening up takes effect immediately. “If you increase the default access, such as from Public Read Only to Public Read/Write, your changes take effect immediately.” The recalculation then runs in the background to remove share rows that are no longer needed.
Locking down waits. “If you decrease the default access, such as from Public Read/Write to Public Read Only, your changes take effect after recalculation is run.” Until it finishes, users still have the old access.

That’s one more reason to start locked. Locking down a big object later is slow, and until it’s done, the records you meant to hide are still open.

And watch for code. You “can’t change the object’s organization-wide sharing setting from private to public” for a custom object when Apex code uses that object’s share entries (same page). Once a developer writes code against the share table, the default is held in place. Chapter 11 covers that code.

What an architect decides here

For every object, its internal default, set by the question: is there even one user who mustn’t see a record?
For every object that has one, its external default, set for the most restrictive outside need you can see coming, never more open than the internal one.
Which standard objects are Controlled by Parent, knowing that the account family moves together.
When to change a default on a big object, knowing that locking down takes effect only after the recalculation.
That no object goes Public Read/Write just because nobody asked: open is a decision, written down, like locked.

Beyond the exam: what AI changes. An agent user is a user like any other, and the default applies to it the same way. A service agent runs as an internal user, so it gets the internal default; an employee agent on an Experience Cloud site runs as the logged-in site user, so it gets the external one (chapter 3, module 7). An object left Public Read/Write is open to every agent user with Read on the object. Before you give an agent the object, check its default.

Explore

Organization-Wide Default Access Settings (opens in a new tab), Salesforce Help (checked 2026-11-07)
Set Your Internal Organization-Wide Sharing Defaults (opens in a new tab), Salesforce Help (checked 2026-11-07)
External Organization-Wide Defaults Overview (opens in a new tab), Salesforce Help (checked 2026-11-07)
Platform Sharing Architecture (opens in a new tab), Salesforce Architects (checked 2026-11-07)