25 Ways, in Eight Sets

Module 1 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: Once a user is inside the office, what decides which records they can open, and how do all those ways fit on one page?

You’ve made it into the building. You’ve made it into the accounting office. Now there are these locked file cabinets. Does everyone in the accounting office get to see every file?

No. Just because you made it into the office, you shouldn’t see every file. That’s this chapter: record access, the file cabinets. Salesforce puts it in one line: “Record-level security lets you give users access to some object records, but not others” (Platform Sharing Architecture (opens in a new tab), Salesforce Architects, checked 2026-11-01).

From 17 ways to 25

I used to have a video called Steve’s 17 ways to share a record. Then there were more. By the time I taught this class in 2023, it was 20. Today it’s 25. Queues, a queue as a record’s owner, are counted as their own way, and so are external account hierarchies for partner and customer sites. And when I checked every way again, against Salesforce’s own lists, the share table’s reasons and the latest releases, three more were missing: Compliant Data Sharing in the industry clouds, calendar sharing, and data category visibility for Knowledge articles.

The count isn’t the point, and it’ll keep moving. There are about 20 ways, depending on how you group them. What matters is that you know them, for two reasons: so that you can pass the exam, and so that you can architect a proper solution. There’s a lot you can do with what’s out of the box, and the code should be saved for the cases that go beyond it.

What counts as a way

A way to share a record is any mechanism that makes a record visible, or not visible, to a user. Not all of them are sharing rules. Some are out of the box, some you configure, and some are code. Some open records, and one set takes access away again.

And not every way works for every user. The license matters, especially for community users. Salesforce’s own example: high-volume users “don’t utilize the sharing model, because their license types don’t support roles” (same page). They get their own ways, in sets 7 and 8.

First the office, then the cabinet

Every way in this chapter assumes the user already has object access: they’re allowed into the office. Record access is a separate set of controls on top of that.

Chapter 1, module 2 taught the rule for where the two meet: the most restrictive wins. Edit on the object and Read Only on the record gives you Read. It’s not additive. Salesforce’s example is the same idea: users with Read and Edit on opportunities and a Read-Only org-wide default “can read all opportunity records, but can’t edit any unless they own the record or are granted other permissions” (same page).

There’s one exception, and it’s way 13. The “View All” and “Modify All” permissions on an object “ignore sharing rules and settings” (same page). Their bigger siblings do the same for every object: View All Data and Modify All Data are user permissions, “not an object-level permission like View All Records” (Factors that Affect Data Access (opens in a new tab), Object Reference, checked 2026-11-01). That’s the one time the office overrides the cabinet. Chapter 4, module 1 covered it.

The map: eight sets, 25 ways

Here’s how I group them. In my deck, each set was one slide with a row of cards, one card per way. I’ve kept that, and I’ve regrouped them into eight sets, because each set answers one question: who, or what, opens the record?

Click to enlarge

Why these sets

Walk down the map and the question changes set by set.

1. The top level. The baseline every object starts from: how locked the cabinets are to begin with, whether managers see what their team owns, and who owns each record. Every design starts here.
2. Sharing rules. The admin opens records by rule, automatically: by what’s on the record, for the public on a site, or by who owns it.
3. By hand. These are typically done through the user interface, by people: share this one record, add someone to this account’s team, put this account in a territory, add a participant to a client’s record, share your calendar with a coworker. That’s why they’re together. Compliant Data Sharing is the one you’ll only meet in the industry clouds, such as Agentforce Financial Services.
4. Built into the platform. Salesforce itself: the permissions that see every record, the access the platform gives you for free between parents and children, and a model of its own for one family of records, Knowledge articles and questions, and nothing else. Salesforce says articles and questions “do not have organization-wide defaults, sharing rules, or manual record sharing”; their data categories decide who sees them (How Category Visibility Differs from Other Salesforce Models (opens in a new tab), Salesforce Help, checked 2026-11-01).
5. Programmatic. When the out-of-the-box ways can’t express the rule, a developer or a flow writes the share. This is the full power of the share table. Programmatic used to mean Apex; now it can be Apex or flows. And code that runs in system mode reads past sharing altogether, in Apex or in a flow: a flow set to System Context without Sharing “can access all data” (Set Flow Run Context (opens in a new tab), Salesforce Help, checked 2026-11-01).
6. Taking access away. Every other set opens a cabinet. This one locks one again, or only filters what a user sees.
7. Community licenses. For some external users, the license decides which tools you have.
8. External hierarchies. How a partner’s or a customer’s own structure shares records up and across.

My deck had seven sets, and code turned up in two of them. Pulling it into its own set makes the line clear: sets 1 to 4 are what Salesforce gives you, set 5 is what you build, and the code should be saved for what the others can’t do.

How the rest of the course follows the map

This chapter touches each way lightly, one set per module. Then Part 2 and Part 3 go deep:

Set	Goes deep in
1. The top level	chapter 6, Org-Wide Defaults, Ownership and the Role Hierarchy
2. Sharing rules	chapter 7, Public Groups and Criteria-Based Sharing Rules; chapter 8, Owner-Based Sharing Rules
3. By hand	chapter 9, Config-Based Sharing: Manual Shares, Teams and Territories (Compliant Data Sharing there too); calendar sharing in chapter 12
4. Built into the platform	chapter 10, Overrides and Implicit Sharing: What You Get for Free; data category visibility in chapter 12, Files, Folders, Reports and Other Data
5. Programmatic	chapter 11, Programmatic Sharing: Apex and Flow Managed Sharing; chapter 17, Sharing When Writing Apex: Secure Code
6. Taking access away	chapter 16, Taking Access Away: Restriction and Scoping Rules
7. Community licenses	chapter 15, Sharing Sets, Share Groups and Data Sharing for High-Volume Users
8. External hierarchies	chapter 14, External Users: Sites, Communities, Licenses and Roles

What an architect decides here

• For each object, which sets the design uses, starting from the top level.
• Which requirements the out-of-the-box sets can meet, and which truly need set 5.
• Whether anything needs taking away after it’s opened, and whether set 6 is the right tool or the model should open less.
• Which users are on community licenses, and which ways their licenses allow.
• That everyone on the team uses the same map, so “how does this user see that record?” has one place to start.

Beyond the exam: what AI changes. An agent opens the same file cabinets. It runs as a user, so every one of the 25 ways decides what it can find, and the same map answers “why can the agent see this record?” What changes is speed: a person might never open the record a careless sharing rule exposed; an agent asked a broad question will. Chapter 20 covers agents.

Explore

• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (checked 2026-11-01)
• Sharing and Record Access Features (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Factors that Affect Data Access (opens in a new tab), Object Reference (checked 2026-11-01)
• How Category Visibility Differs from Other Salesforce Models (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Set Flow Run Context (opens in a new tab), Salesforce Help (checked 2026-11-01)