Study guide

Study guide for chapter 5 of the Securing Salesforce: Sharing and Visibility course. Read the nine modules first; this page helps you check what stuck.

About this study guide. It’s built only from this course’s own content and the published Salesforce exam guide’s list of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.

This chapter is the map for the exam’s biggest section, Access to Records, 39% of the exam. It touches all nine of that section’s objectives: org-wide defaults, the role hierarchy, sharing rules, groups, teams, the object relationships that support sharing, programmatic sharing, sharing with external users, and record access overrides. Here you learn what each way is and where it sits on the map; Parts 2 and 3 take each one apart. The exam guide aligns to Winter ‘23, so the changes since then are in their own list at the end.

For the Exam

Tick them off as you go. Each one links to where it’s taught.

The map (supports all of REC-1 to REC-9)

• I can name the eight sets and say who or what opens the record in each: the top level, sharing rules, by hand, built into the platform, programmatic, taking access away, community licenses, external hierarchies. (The map)
• I know every way assumes object access, and the most restrictive of object and record access wins. (First the office, then the cabinet)
• I know not every way works for every license. (What counts as a way)

Set 1, the top level (supports REC-1, REC-2)

• I know the org-wide defaults, Private, Public Read Only and Public Read/Write, plus Controlled by Parent for details, and that internal and external defaults are set apart. (Way 1)
• I know the external default can’t be more permissive than the internal one, and guest users’ defaults are Private. (Way 1)
• I know Grant Access Using Hierarchies follows the owner’s role, and can be turned off only for custom objects. (Way 2)
• I know the owner has full access, and not every object has an owner. (Way 3)
• I know a queue can own a record, and each queue has its own hierarchy setting, with the object’s setting winning. (Way 4)

Set 2, sharing rules (supports REC-3, REC-4)

• I know rules only open records, need a Private or Public Read Only default, and the most permissive rule wins. (What every sharing rule has in common)
• I know criteria-based rules use field values on the record, and can’t use formula, encrypted or derived fields. (Way 5)
• I know a guest user rule is the only way to give unauthenticated users record access, and shares with anyone. (Way 6)
• I know owner-based rules share records owned by a group or role, and that high-volume users can’t be in them. (Way 7)
• I know the difference between sharing with a role and a role and subordinates, and what a public group can contain. (The target)
• I know the limits: up to 300 sharing rules per object, including up to 50 criteria-based or guest user rules. (The limits)

Set 3, by hand (supports REC-5)

• I know who can share a record manually: the owner, someone above them, a user with Modify All Records, or an admin. (Way 8)
• I know manual shares are deleted when the owner changes, by default. (The owner changes)
• I know the three kinds of team, account, opportunity and case, and how case teams differ. (Way 9)
• I know territories put accounts and users in buckets, and work on accounts, not custom objects. (Way 10)

Set 4, built into the platform (supports REC-6, REC-9)

• I know View All and Modify All override sharing, and View All Data and Modify All Data do it for every object. (Way 13)
• I know child-to-parent implicit sharing: see a child case, contact or opportunity, and read its account. (Child to parent)
• I know parent-to-child access is set by the account owner’s role, and only applies to Private children, not Controlled by Parent. (Parent to child)
• I know a site user who is the contact on a case gets Read and Write on it. (Site and portal users)

Set 5, programmatic (supports REC-7)

• I know programmatic sharing is inserting a share record, from Apex, a flow or the API. (Way 16)
• I know the four pieces of a share record: which record, who, how much (Read or Edit, never All), and why, the row cause. (The pieces of a share record)
• I know shares with an Apex sharing reason survive an owner change, and Manual ones don’t. (Sharing reasons)
• I know what programmatic sharing has to watch: record changes, user changes, criteria changes and data volume. (The work behind it)

Set 7 and Set 8, external users (supports REC-8)

• I know high-volume users have no role and no share table, and which ways that rules out. (The cheap seats)
• I know sharing sets bring in records linked to the user’s account or contact, and share groups share out what high-volume users own. (In and out)
• I know account relationship data sharing rules share one account’s records with another. (Way 22)
• I know external roles sit under the account owner, and how partner and customer super users differ. (Way 23, Way 24)

What changed since the exam’s Winter ‘23 alignment (dated, beyond the exam today)

• I know the ways added to the map since: queues as their own way, external account hierarchies, Compliant Data Sharing, calendar sharing and data category visibility. (From 17 ways to 25)
• I know restriction rules and scoping rules: one takes access away, the other only filters. (Way 18, Way 19)
• I know since Summer ‘23, child implicit shares for cases and contacts aren’t stored. (The share table: what Set 4 writes)
• I know since Summer ‘26, Apex runs in user mode by default, and system mode with without sharing reads past sharing. (System mode and the class’s sharing keyword)
• I know Winter ‘27 added an org setting to keep manual shares when records are transferred, off by default. (The owner changes)
• I know that since October 2026, standard objects can have custom row causes, so code-written shares survive an owner change. (Standard objects)

Beyond the Exam

The exam is the floor, not the ceiling. These are the habits from this chapter that an architect needs, whether or not a question ever asks about them.

• Start at Private if even one user must not see a record. It’s easier to open up later than to lock down later.
• Ask how many there will be before you build a sharing rule. More than about ten of the same pattern, and a rule is the wrong tool.
• Never hard-code IDs in a sharing rule. It won’t deploy, and your sandboxes stop matching production.
• Read every rule that targets a group before you add someone to it.
• Save code for what Sets 1 to 4 can’t do, and when you write shares, give them a reason of your own.
• Every piece of code in system mode has a reason and a reviewer.
• Open less before you take away. A restriction rule is a narrow tool, with two or five per object.
• Know which seat each external user sits in before you design their access.
• Start with the share table when someone asks who can see a record, and don’t stop there.
• Don’t build on share rows you didn’t write. Salesforce may stop storing some.

Words to Know

Term	In one line
Org-wide default	How locked each object’s records are before any other way opens them
Grant Access Using Hierarchies	Users above the owner in the role hierarchy get the owner’s access
Queue	A group that can own records; its members see what it owns
Share table	The table behind an object that holds a row for each share, such as AccountShare
Row cause	Why a share row exists: Owner, Rule, Manual, Team, or a reason of your own
Criteria-based sharing rule	Shares records by their field values
Owner-based sharing rule	Shares records by who owns them
Public group	A set of users, roles and other groups, used as a target for sharing
Implicit sharing	Access Salesforce gives between parents and children without a rule
Apex sharing reason	A custom row cause; shares with one survive an owner change
System mode	Code that runs without the user’s object, field and, with without sharing, record access
Restriction rule	Narrows the records a user can see, on top of sharing, for good
Scoping rule	Filters list views, reports and SOQL by default; the user can switch it
High-volume user	An external user with no role and no share table, in the cheap seats
Sharing set	Gives site users records linked to their account or contact
Share group	Shares records high-volume users own with internal and other users
Super user	An external user who can see records of others at their company

Check Yourself

Short scenarios in the style of the course. Decide your answer before you open it.

1. Everyone in sales may see every account, except one small team that must never see one region's accounts. What's the org-wide default for accounts?

Private. If even one user must not see a record, start the object at Private and open it with the other ways. Every other set opens records up from the default; only Set 6 takes them away again. Reread Way 1.

2. Someone proposes a criteria-based sharing rule for each US state, sharing with a group per state. What do you say?

Ask how many there will be. Fifty states is the whole limit of 50 criteria-based or guest user rules on that object, with nothing left for anything else, and someone will ask for one more. Look for another pattern, such as territories or one group per region. Reread The limits.

3. You share a record with a manager's role. Their assistant manager, one level below, can't help work it. Why, and what's the fix?

Sharing with a role gives that role, and those above it through the hierarchy, access; not the roles below. Share with the role and subordinates instead, so the people who do the work can see it. Reread The target.

4. A user who owns no accounts and is on no sharing rule can read one account. What's the first explanation to check?

Implicit sharing: they can see one of the account’s children, a case, contact or opportunity, by ownership or sharing, so they get Read on the account. Look in the share table for an ImplicitParent row. Reread Child to parent.

5. Code shares accounts with a support group using the Manual row cause. After an account changes owner, the group can't see it. What happened, and what are the two fixes today?

Manual shares are deleted when the owner changes, and on a standard object Manual was the only reason code could use. Today, give the code a custom row cause on the account, which survives an owner change, or turn on the org setting to keep manual shares when records are transferred. Reread Standard objects.

6. A restriction rule hides closed tasks from a team. One team member still sees every task through a custom component. Why?

Restriction rules don’t apply to code running in system mode, or to users with View All. Check the component’s Apex: system mode with a without sharing class reads past every way, restriction rules included. Reread What a restriction rule can’t narrow.

7. Customers on a high-volume license need to see their company's orders. Can you use an owner-based sharing rule?

No. High-volume users have no role, so they can’t be in owner-based sharing rules or public groups. Use a sharing set: the orders need a lookup to the account, and each user sees the orders on their own account. Reread Way 20.

8. You query the share table to explain why a user can see an account, and find no row for them. Does that mean they shouldn't see it?

No. Several ways write no row: the role hierarchy, View All and Modify All, system mode, sharing sets, and, for cases and contacts, child implicit access. Check those next. Reread What the share table doesn’t show.

Explore

• Salesforce Certified Platform Sharing and Visibility Architect Exam Guide (opens in a new tab), Salesforce Help (checked 2026-11-01)

The official list of objectives and their weights. Always check the current version before you book an exam.