Defaults, Hierarchy, Ownership, Queues

Module 2 of 9 in the chapter Steve’s 25 Ways to Share a Record: The Map, chapter 5 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: What decides who can see a record before anyone writes a single rule, and where can you see that decision in the data?

Set 1 is the top level of sharing. Every object starts here, before any rule, team or line of code. Four ways: the org-wide defaults, grant access using hierarchies, ownership, and queues.

If you’re building record access for anything, go to Sharing Settings in Setup. That’s your very first stop on the road.

Click to enlarge

Way 1: org-wide defaults

First you decide how wide open each object is. Salesforce’s own words: “Organization-wide defaults specify the default level of access that users have to each others’ records” (Sharing and Record Access Features (opens in a new tab), Salesforce Help, checked 2026-11-01).

The choices are Public Read/Write, where anyone who can see the object can see and edit every record; Public Read Only, where everyone can see every record but only some can edit; and Private, where you can’t see a record unless you’ve been granted access. Detail records in a master-detail relationship can be Controlled by Parent, which chapter 4, module 5 used.

Here’s the rule I give my clients. When you’re doing accounts, I ask: is there anyone you need to hide these accounts from? If there’s even a single user in your system you need to hide a record from, even one, then you’re probably going to dial the org-wide default down to Private. Salesforce says the same in its architecture guide: “You use organization-wide sharing settings to lock your data to the most restrictive level. Use the other record-level security and sharing tools to selectively give access to other users” (Platform Sharing Architecture (opens in a new tab), Salesforce Architects, checked 2026-11-01).

And it’s easier to open up later than to lock down later. Every other way in this chapter opens records up from the default. Set 6 is the only one that closes them again.

There are two defaults per object, not one: Default Internal Access and Default External Access. External org-wide defaults “provide separate organization-wide defaults for internal and external authenticated users,” and “The external access level for an object can’t be more permissive than the internal access level.” Guest users are a case of their own: their defaults “are set to Private for all objects” (External Organization-Wide Defaults Overview (opens in a new tab), Salesforce Help, checked 2026-11-01).

Way 2: grant access using hierarchies

Next to each default is a checkbox: Grant Access Using Hierarchies. It applies the role hierarchy. “The role hierarchy automatically grants users access to the records owned by or shared with their subordinates in the hierarchy” (Sharing and Record Access Features).

It takes the owner field. Whoever owns the record, everyone above them in the role hierarchy gets access too. So watch where owners sit. If the owner is low in the hierarchy and has many people above them, that’s a lot of sharing cascaded upwards.

You can turn it off, but only for custom objects. “You can control sharing access using hierarchies for any custom object, but not standard objects” (same page). For standard objects, it’s always on.

Way 3: ownership

The third way is the simplest: the owner sees the record. Salesforce puts it strongly: “Record ownership and full access are synonymous and interchangeable and provide the user with the highest level of access to a record” (Platform Sharing Architecture).

Each record has one owner, in its Owner field. Not every object has one: a detail record in a master-detail relationship has no owner of its own, which is why its default is Controlled by Parent. And the owner matters twice. The owner sees the record, and the owner’s place in the role hierarchy decides who above them sees it through way 2.

Way 4: queues

A record doesn’t have to be owned by a person. It can be owned by a queue. Queues “help you prioritize, distribute, and assign records to teams who share workloads,” and “Queues are available for cases, contact requests, leads, orders, custom objects, service contracts, and knowledge article versions” (Sharing and Record Access Features).

Who sees a record a queue owns? Its members. And each queue has its own Grant Access Using Hierarchies setting: “When selected, any records shared with users in this queue are also shared with users higher in the hierarchy.” The object’s setting still wins: if it’s off for the object in Sharing Settings, records “aren’t shared with users higher in the hierarchy, even if you enable Grant Access Using Hierarchies for the queue” (Create Queues (opens in a new tab), Salesforce Help, checked 2026-11-01).

That’s why queues are their own way. A support case sitting in a queue is seen by the people who might pick it up, before anyone owns it.

Here’s something some people don’t know exists. Behind each object Salesforce shares, there’s a second table, the share table. For accounts, it’s AccountShare. For a custom object of mine called Banana, it’s Banana__Share. In class, I open it in Workbench and query it, and you can use any tool that runs a SOQL query.

Every row says three things: who has access (a user or a group), how much (the access level), and why (the row cause). For an account, the access level is Read, Edit or All, and the first row cause you’ll see is the owner’s: “Owner—The User is the owner of the Account” (AccountShare (opens in a new tab), Object Reference, Winter ‘27, checked 2026-11-01).

That’s Set 1 in the data. The org-wide default isn’t a row: it’s the starting point that rows are added to. Grant access using hierarchies isn’t a row on the record either. The owner is. As we go through the sets, you’ll watch this table grow: rule rows, team rows, manual rows, and rows that code writes. Module 9 covers the ways that never write a row at all.

Click to enlarge

Where this goes deep

Chapter 6, Org-Wide Defaults, Ownership and the Role Hierarchy, takes each of these apart: which default for which object, designing the hierarchy, ownership skew, ownerless objects and queue design. For now, know the four, and know that every design starts here.

What an architect decides here

For each object, its default internal access and default external access, starting from “is there anyone we need to hide this from?”
For each custom object, whether Grant Access Using Hierarchies stays on.
Who owns records, and where owners sit in the role hierarchy, so access doesn’t cascade further than it should.
Which objects use queues, who the members are, and whether each queue grants access up the hierarchy.
That someone can read the share table and explain each row.

Beyond the exam: what AI changes. When you build an agent, you choose its user, and that user owns records the agent creates. Where that user sits in the role hierarchy decides who above it sees those records through way 2. Give agent users a place in the hierarchy on purpose, not by default. Chapter 20 covers agents.

Explore

Sharing and Record Access Features (opens in a new tab), Salesforce Help (checked 2026-11-01)
External Organization-Wide Defaults Overview (opens in a new tab), Salesforce Help (checked 2026-11-01)
Create Queues (opens in a new tab), Salesforce Help (checked 2026-11-01)
AccountShare (opens in a new tab), Object Reference (checked 2026-11-01)
Platform Sharing Architecture (opens in a new tab), Salesforce Architects (checked 2026-11-01)