Org-Wide Defaults, Ownership and the Role Hierarchy

Chapter 6 of Securing Salesforce: Sharing and Visibility, Part 2: The File Cabinets: Sharing Records. New to the course? Start with chapter 1.

Part 1 got people through the front door and into the right offices. Part 2 opens the file cabinets: which records each person sees. And it starts where every sharing design starts, with the first three ways from the map: the org-wide default, the role hierarchy, and the owner.

In class I call the sharing settings your very first stop. Everything else in Part 2 opens records up from the baseline you set here. So set it on purpose: if there’s even one user in your system you want to hide a record from, the default is Private. It’s easier to open up later than to lock down later.

The ideas in this chapter

Two rules decide access. The most restrictive wins between the office and the cabinet; the most generous grant wins inside the cabinet.
Every grant has a home. Most are rows in a share table; some come from groups, the hierarchy or the platform itself.
Set each default for the user who mustn’t see. Private if even one must not; and a separate, never more open, default for outsiders.
The owner holds the first key. A person, a queue or a system user, and it moves when the owner changes.
Design the role hierarchy for access, not as an org chart. Each role is a level of data access, and every move is a recalculation.
The hierarchy sends records to the top. Confidential records need a design that stops them: a branch of their own, no role, a queue, or the hierarchy turned off.
The data model shares before you do. Master-detail and Controlled by Parent decide a child’s access from its parent.
The user record is a record too. Who can see whom is a sharing decision of its own.

The picture

Here’s where the chapter starts: the four kinds of grant that can give someone a record.

Click to enlarge

And the first decision for every object: how locked its cabinet starts.

Click to enlarge

The path through this chapter

Seven modules, each standing on its own.

Under the Hood: How Salesforce Decides Who Can See a Record. The two rules; four kinds of grant; the object’s table, its share table and the group tables; access worked out in advance, and what that costs.
Org-Wide Defaults: How Locked Each File Cabinet Starts. Private, Public Read Only and Public Read/Write; the special objects; internal and external defaults; changing a default.
Ownership and Queues: Who Holds the Key to Each Record. What an owner gets; objects without owners; queues as owners; what moves, goes or stays when the owner changes.
The Role Hierarchy: Design It for Access, Not as an Org Chart. What the hierarchy does; draw it first; every role is a sharing decision; depth and count; overlays.
Confidential Records: Start at the Top of the Hierarchy. The CEO and the complaint; five ways to keep a record from the top, and what gets through anyway.
Master-Detail and Controlled by Parent: When the Data Model Shares for You. Lookup or master-detail, for sharing; the Sharing Setting; junction objects and both masters.
Who Can See Other Users: The User Record Is a Record Too. The User default; View All Users; user sharing rules; reports and the users in them.

Then check what stuck with the study guide.

What an architect decides here

For every object, its internal default, set by asking whether even one user mustn’t see a record, and its external default, never more open.
For every object, who owns its records: a person, a queue or a system user, and what happens when the owner changes.
The role hierarchy, drawn before it’s built, each role a level of data access, kept shallow, with overlays placed on purpose.
For every confidential object, how its records are kept from the top, and who still holds the overrides.
For every child object, lookup or master-detail, decided with the sharing question asked.
Whether users may see each other, and how that’s tested.
When the expensive changes run: default changes, role moves and owner changes on many records.

Beyond the exam: what AI changes. An agent runs as a user, so it starts from the same baseline as everyone else: the defaults, the owner and the hierarchy above it. Give an agent’s user a role high in the tree, and it inherits every record below. Place agent users like any other user: for the access they need, not for convenience. Chapter 20 covers agents.

Explore

Each module lists its own sources. Two to start with:

Record-Level Access: Under the Hood (opens in a new tab), Salesforce Developers (checked 2026-11-07)
Group Membership Operations and Sharing Recalculation (opens in a new tab), Designing Record Access for Enterprise Scale, Salesforce Developers (checked 2026-11-07)

Next: Public Groups and Criteria-Based Sharing Rules