Steve's 25 Ways to Share a Record: The Map

Dette indhold er ikke tilgængeligt i dit sprog endnu.

Chapter 5 of Securing Salesforce: Sharing and Visibility, Part 1: The Front Door and the Offices. New to the course? Start with chapter 1.

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. Chapters 2 to 4 were the front door and the offices. This chapter is the file cabinets: every way a record is opened, or closed again, to a user. I used to call it Steve’s 17 ways to share a record. Then 20. Today it’s 25, in eight sets, because each set answers one question: who, or what, opens the record?

The ideas in this chapter

A way is anything that makes a record visible, or not. Not all of them are sharing rules. Some are out of the box, some you configure, and some are code.
First the office, then the cabinet. Every way assumes object access. The most restrictive wins, except View All and Modify All, which override sharing.
Every design starts at the top level. The org-wide default, grant access using hierarchies, ownership and queues. If even one user must not see a record, start at Private.
Rules open records automatically. Criteria-based, guest user and owner-based rules: which records, who, and how much. Up to 300 per object, including up to 50 criteria-based or guest user rules.
People open records by hand. Manual shares, teams, territories, Compliant Data Sharing and calendar sharing. Since Winter ‘27, keeping manual shares on an owner change is a choice.
The platform opens some by itself. View All and Modify All, implicit sharing between parents and children, and data categories for Knowledge.
Programmatic sharing is inserting a record into the share table. Which record, who, how much, and why. Code can also skip sharing in system mode, only on purpose.
One set takes access away. Restriction rules narrow what sharing opened, for good. Scoping rules only filter, and the user can switch them off.
The license decides the tools. High-volume users have no role and no share table: sharing sets bring records in, share groups send theirs out.
Customers and partners have their own structure. External roles, super users and external account hierarchies share records up and across.
The share table records most of it, not all of it. Know which ways write a row, and where to look for the ones that don’t.

The picture

Here’s the map the whole chapter, and Parts 2 and 3 of the course, follow.

Click to enlarge

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. Set 6 is the only set that closes cabinets again. Sets 7 and 8 are for users outside your company.

The path through this chapter

Nine modules, each standing on its own.

Into the File Cabinets: 25 Ways, in Eight Sets. From 17 ways to 25; what counts as a way; first the office, then the cabinet; and the map.
Set 1, The Top Level. Org-wide defaults, grant access using hierarchies, ownership and queues; and the share table’s first row, the owner’s.
Set 2, Sharing Rules. Criteria-based, guest user and owner-based rules; the public group as a Swiss Army knife; the limits of 50 and 300; and Steve’s number of zeros.
Set 3, By Hand. Manual sharing and Winter ‘27’s keep-manual-shares setting; account, opportunity and case teams; sales territories; Compliant Data Sharing; calendar sharing.
Set 4, Built Into the Platform. View All and Modify All; implicit sharing, the hidden rules; data category visibility for Knowledge.
Set 5, Programmatic. Inserting a share record: its four pieces, in Apex and in a flow; sharing reasons and the new custom row causes on standard objects; system mode in code.
Set 6, Taking Access Away. Restriction rules, strict; scoping rules, soft; open, then narrow; and the last resort.
Set 7, Community Licenses. The stadium’s cheap seats; sharing sets in, share groups out; account relationship data sharing rules.
Set 8, External Hierarchies. External roles, super users and external account hierarchies; then what the share table doesn’t show, and what’s beyond the record.

All through the chapter, one account’s share table grows, a set at a time: the owner’s row, rule rows, manual, team and territory rows, the implicit parent row, and your own code’s row. Then the last module asks where to look for everything that never writes a row.

Click to enlarge

Then check what stuck with the study guide.

What an architect decides here

For each object, which sets the design uses, starting from the top level and the question “is there anyone we need to hide this from?”
For each requirement, whether a rule, a person, the platform or code opens the record, and how many of each there will be.
Who holds View All, Modify All, View All Data and Modify All Data, and which code runs in system mode, each with a reason and a reviewer.
Whether manual shares are kept when records change owner, and which code moves to a sharing reason of its own.
Whether anything needs taking away, and whether a restriction rule is the right tool or the model should open less.
Which seat each external user sits in, and so which ways can reach them.
That someone can explain every row in the share table, and knows where to look for the ways that write none.

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 and reach: an agent asked a broad question reads everything its user can reach, and an action that runs in system mode reads past all 25. Chapter 20 covers agents.

Explore

Each module lists its own sources, each checked 2026-11-01. Two to start with:

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)

Next: Part 2 begins with Org-Wide Defaults, Ownership and the Role Hierarchy (coming soon)