تخطَّ إلى المحتوى
SteveTechArcSteveTechArc Courses

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

Section titled “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

Section titled “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

Section titled “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

Section titled “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?

Steve's 25 ways to share a record, in eight sets Steve's 25 ways to share a record, in eight sets, each set answering who or what decides. Set 1, the top level, the baseline: 1 org-wide defaults, 2 grant access using hierarchies, 3 ownership, 4 queues. Set 2, sharing rules, the admin by rule: 5 criteria-based, 6 guest user, 7 owner-based. Set 3, by hand, people record by record: 8 manual sharing, 9 teams, 10 territories, 11 Compliant Data Sharing in industry clouds, 12 calendar sharing. Set 4, built into the platform: 13 View All and Modify All, on an object or on all data, 14 implicit sharing, 15 data category visibility, for Knowledge articles and questions only. Set 5, programmatic, a developer or a flow: 16 programmatic sharing, 17 system mode in Apex or a flow. Set 6, taking access away: 18 restriction rules, 19 scoping rules, which filter but don't secure. Set 7, community licenses: 20 sharing sets, 21 share groups, 22 account relationship data sharing rules. Set 8, external hierarchies: 23 external role hierarchy, 24 super user, 25 external account hierarchies. Footnote: most restrictive wins; a way opens a record only as far as the user's object access allows. {"author": "Steve Simpson", "blueprint": "1.0.1", "builder": "standard 1.57.0", "built": "2026-10-30", "id": "DGM-SVA-WS-01", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} THE SET, AND WHO DECIDES THE WAYS Set 1: The top level the baseline 1 Org-wide defaults how locked, to begin with 2 Hierarchies grant access using hierarchies 3 Ownership one owner per record 4 Queues a queue as the owner Set 2: Sharing rules the admin, by rule 5 Criteria-based by what's on the record 6 Guest user for the public, on a site 7 Owner-based by who owns the record Set 3: By hand people, record by record 8 Manual sharing one record, shared by a person 9 Teams account, opportunity, case 10 Territories accounts, by territory 11 Compliant Data Sharing participants, in industry clouds 12 Calendar sharing a user shares their events Set 4: Built into the platform Salesforce itself 13 View All, Modify All every record: an object, or all data 14 Implicit sharing parent and child, built in 15 Data category visibility Knowledge articles and questions only Set 5: Programmatic a developer or a flow 16 Programmatic sharing Apex or a flow writes the share 17 System mode Apex or a flow, on purpose Set 6: Taking access away the admin, narrowing 18 Restriction rules takes access away 19 Scoping rules filters, doesn't secure Set 7: Community licenses the license decides 20 Sharing sets through the user's account or contact 21 Share groups share what community users own 22 Account relationship data sharing rules between related accounts Set 8: External hierarchies the partner or customer structure 23 External role hierarchy partner and customer roles 24 Super user sees other users' records 25 External account hierarchies child accounts, up to the parent Most restrictive wins: a way opens a record only as far as the user's object access allows. HOW TO READ IT opens access takes it away, or only filters for external users © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Why these sets

Section titled “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

Section titled “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:

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

What an architect decides here

Section titled “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

Section titled “Explore”