Study guide

Study guide for chapter 8 of the Securing Salesforce: Sharing and Visibility course. Read the four 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 finishes one objective from the exam section Access to Records, the biggest section at 39% of the exam: sharing rules. Chapter 7 taught criteria-based and guest user rules; this chapter teaches owner-based rules and how to choose between them. The exam guide aligns to Winter ‘23, and a few things have changed since then, so those are in their own list at the end. Know both, and know which date each belongs to.

For the Exam

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

How an owner-based rule works (supports REC-3)

• I know an owner-based rule shares records by who owns them, not by anything on the record. (The source is the owner)
• I know the five steps: name and description, type, owned by members of (the source), share with (the target), and the access level. (Five steps to build one)
• I know the levels: Read Only or Read/Write, with contacts, opportunities and cases set on account rules, and Full Access for campaigns only. (The level, and the profile behind it)
• I know the target also needs the object permissions to match the level, and that the most permissive of several rules wins. (The level, and the profile behind it)
• I know what makes Salesforce re-evaluate one: a new record, a new owner, a change of people in the source or target, a change to the rule, and never a field edit. (What Salesforce watches)
• I know rules apply to inactive owners’ records too. (Four things that surprise people)
• I know a queue as a source shares only records the queue owns, not its members’ records, and can’t be a target. (Four things that surprise people)
• I know high-volume site users, Chatter External and Chatter Free users can’t be in owner-based rules. (Four things that surprise people)
• I know a new rule with the same source and target overwrites the existing one. (Four things that surprise people)
• I know only the label, rule name and access level can be edited: the source and target are final. (Some choices are final)

Source and target (supports REC-3)

• I know the categories for both sides: public groups, roles, Roles and Internal Subordinates, territories, queues (source only) and manager groups. (The categories)
• I know choosing Roles, Internal and Portal Subordinates or Portal Roles as a target reaches external users, and Salesforce alerts you on save. (The categories)
• I know the hierarchy always carries a rule’s access up, and subordinates carry it down only if you choose them. (Go downward, or not)
• I know when one rule to a group replaces several rules with the same source. (One rule, or several)
• I know opportunity, contact and case rules also give access to the parent account, and account rules set access to the children. (What else the rule reaches)

Owner-based or criteria-based (supports REC-3)

• I know the question: does access follow a person or team (owner-based) or a value on the record (criteria-based)? (Follow the owner, or follow the record)
• I know what happens on a transfer: owner-based access moves with the owner; criteria-based access stays with the value. (What each one follows)
• I know the budget: 300 rules per object, including up to 50 criteria-based or guest user rules. (The 50 inside the 300)
• I know not to write a criteria-based rule on Owner equals one user. (Don’t fake one with the other)
• I know when a requirement needs both, a field filled by an automation brings the owner onto the record. (When the answer is both)

When people move (supports REC-3)

• I know what moving one user to another role does: managers above the old role lose access, managers above the new role gain it, and rules with either role as a source are recalculated. (Moving one user)
• I know moving a whole role does that work for every user in it. (Moving a whole role)
• I know ownership skew starts above 10,000 records of an object for one owner, and to keep those owners out of source groups. (Big owners in a source group)
• I know group membership changes take locks, and that reparenting roles blocks almost all other group updates. (Locks)
• I know the habits: rehearse in a recently refreshed full copy sandbox, bottom up, off-peak, serial, with retries, and deferred sharing calculations for the biggest realignments. (Habits for big changes)

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

• I know Roles and Subordinates is now deprecated as a rule category; use Roles and Internal Subordinates. Chapter 7, module 1 has the dates. (The categories)
• I know the scale advice in this chapter comes from the Winter ‘27 edition of Designing Record Access for Enterprise Scale, checked 2026-11-07, where granular locking is on by default. (Locks)

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.

• Put groups on both sides, because neither side can change after saving.
• Ask “go downward?” for every role in a target.
• Decide the children on every account rule: contacts, opportunities and cases.
• Ask what a transfer should do before you choose the kind of rule.
• Know who owns the most records of each object, and keep them out of source groups.
• Keep a list of source roles and groups, so every reorganization starts with it.
• Remove rules that give access people already have through the hierarchy.
• Rehearse a reorganization in a recently refreshed full copy sandbox.

Words to Know

Term	In one line
Owner-based sharing rule	A rule that shares records by who owns them
Source (owned by members of)	The people whose records the rule picks up
Target (share with)	The people who receive the records
Roles and Internal Subordinates	A role and the internal roles below it, without site or portal roles
Roles, Internal and Portal Subordinates	A role and every role below it, including site and portal roles
Go downward	Including subordinates in a target so access flows down the branch
Re-evaluation	Salesforce adding and removing a rule’s share rows after a change
Transfer	Changing a record’s owner, which re-evaluates owner-based rules
Ownership skew	One user owning more than 10,000 records of an object
Group membership lock	The lock Salesforce takes on group tables while membership changes
Deferred sharing calculations	Suspending sharing rule and group membership calculations during a big change, then resuming them

Check Yourself

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

1. Accounts are Private. The sales reps want to see each other's accounts. What's the simplest rule?

An owner-based rule with the Sales Rep role, or a group holding it, as both the source and the target. Salesforce uses this exact example. Reread Same bucket on both sides.

2. A rule shares Read/Write, but users in the target can only read the records. Why?

Their profile and permission sets give Read, not Edit, on the object. The rule’s level is the most it gives, not the most a user gets; the most restrictive wins between the office and the cabinet. Reread The level, and the profile behind it.

3. An owner-based rule's source is a support queue. The queue's members own many cases themselves. Are those shared?

No. A rule on a queue shares only records the queue owns, not records owned by its members. Reread Four things that surprise people.

4. You create a second owner-based rule with the same source and target as an existing one, but Read Only instead of Read/Write. What happens?

It overwrites the existing rule, and its access level with it. You don’t get two rules. Reread Four things that surprise people.

5. Records owned by the region 2 VP's team must reach the region 2 VP and the managers below them, but not region 1. Which target?

Region 2 VP, Roles and Internal Subordinates. That goes downward through region 2’s branch and skips region 1. The senior VP above gets them through the hierarchy either way. Reread Go downward, or not.

6. A rule shares accounts with the support desk. Should support be able to edit every opportunity on those accounts?

Decide it on purpose. An account rule sets access to the accounts and separately to their contacts, opportunities and cases, where Private is an option. Reread What else the rule reaches.

7. "Every case marked Escalated goes to the escalation team, whoever owns it." Owner-based or criteria-based?

Criteria-based. Access follows a value on the record, not the owner; a transfer shouldn’t change who sees it. Reread Follow the owner, or follow the record.

8. Someone writes a criteria-based rule: Owner equals one user's ID. What's wrong?

It hard-codes an ID that won’t travel between orgs, covers one person instead of a team, and spends one of the 50. If access follows the owner, use an owner-based rule. Reread Don’t fake one with the other.

9. An admin moves one rep from the region 1 role to region 2. What does Salesforce recalculate?

The hierarchy access above both roles for everything the rep owns, and every sharing rule whose source includes either role: the rep’s records leave the old rules and join the new ones. Some rules may no longer fit. Reread Moving one user.

10. An integration user owns 300,000 accounts and sits in a group used as a rule's source. What's the risk, and the fix?

Ownership skew: every change to that group, or to the user’s role, moves rows for all 300,000 records, with long recalculations and locks. Spread ownership under 10,000 per owner, and keep big owners out of source groups. Reread Big owners in a source group.

Explore

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

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