Study guide
Study guide for chapter 7 of the Securing Salesforce: Sharing and Visibility course. Read the six 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 teaches two objectives from the exam section Access to Records, the biggest section at 39% of the exam: sharing rules and groups. Chapter 8 finishes sharing rules with owner-based rules. The exam guide aligns to Winter ‘23, and several 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
Section titled “For the Exam”Tick them off as you go. Each one links to where it’s taught.
Public groups (supports REC-4)
- I know group membership alone grants nothing: access comes from a rule, a manual share or code that shares to the group. (A group is a bucket)
- I know where public groups are used: sharing rules, manual shares, report and dashboard folders, list views, CRM Content libraries and Knowledge actions. (A group is a bucket)
- I know what a group can hold: users, other groups, roles, roles with their subordinates, and territories, and that guest users and high-volume site users can’t be in one. (What goes in the bucket)
- I know the difference between Roles and Internal Subordinates and Roles, Internal and Portal Subordinates. (What goes in the bucket)
- I know to target one group with one rule, then change the group, and that only admins and delegated admins can change a group. (One rule, one group)
- I know a group has its own Grant Access Using Hierarchies setting, and to leave it off for All Internal Users and when managers don’t need the access. (The group’s own hierarchy switch)
- I know the guidance for healthy groups: no more than five levels of nesting, and care above 10,000 members. (Keep the buckets healthy)
- I know personal groups are for one user’s manual shares, in Classic only, and manager groups follow the Manager field, not the role hierarchy, and can’t go inside other groups. (Two other kinds of group)
Criteria-based sharing rules (supports REC-3)
- I know the three parts of every rule: source, target and level. (The three parts of every rule)
- I know a rule writes share rows when it’s saved, and applies to new and existing records; when a record stops matching, the access goes. (What happens when you save)
- I know which fields a rule can read, and that it can’t use other lookups, formula fields, encrypted fields or fields on related records; copy the value into a field first. (Design the field you share on)
- I know text criteria are case-sensitive, blanks are a trap, and record type rules read the label. (Design the field you share on)
- I know the targets and levels: Read Only or Read/Write, Full Access for campaigns only, and the hierarchy still applies to what a rule gives. (The target and the level)
- I know criteria-based rules can share records owned by users who can’t have a role, and that older rules must be recreated to include them. (Records owned by users without a role)
- I know the target can’t be changed after saving, and that you can’t create or test criteria-based rules with Apex. (Some choices are final)
Guest user sharing rules (supports REC-3)
- I know a guest user sharing rule is the only way to give records to unauthenticated guests, and only Read Only. (The only way in)
- I know Secure guest user record access is always on: Private defaults, no queues or groups, no manual or Apex sharing. (The only way in)
- I know the two locks: the guest profile gives objects and fields, the rule gives records. (Two locks)
- I know guest rules count in the 50, and that Product2 can only have guest user sharing rules. (Design the criteria for the public)
- I know records guests create go to a default owner or a queue, rules use CreatedById, and the guest loses access after saving. (Records guests create)
Limits and design (supports REC-3 and REC-4)
- I know the limits: 300 rules per object, including up to 50 criteria-based or guest user rules. (The limits)
- I know to count the buckets before choosing rules, to collapse values into fewer buckets, and when territories, programmatic sharing or sharing sets fit instead. (First, fewer buckets and When the zeros outgrow rules)
- I know why a rule that matches a record ID breaks between orgs, and to share on a name or a code instead. (Why an ID doesn’t travel and What to share on instead)
- I know sharing rules deploy as SharingRules metadata, one file per object, with the target by name. (What the deployment carries)
List views (supports REC-4)
- I know sharing a list view shares the filter, never the records. (What a list view shares)
- I know a list view is shared with groups, roles and territories, never one user, and that “all users” includes partner and customer portal users. (Who you can share it with)
- I know a private list view can show a field the page layout hides, so field-level security is the control. (The list view bleed)
What changed since the exam’s Winter ‘23 alignment (dated, beyond the exam today)
- I know Roles and Subordinates is deprecated in groups, and that in orgs created before February 8, 2024 that enabled digital experiences before Winter ‘26, those members became Roles, Internal and Portal Subordinates. (What goes in the bucket)
- I know that in Summer ‘26, criteria-based rules started recalculating in parallel after org-wide default changes. (Recalculation)
- I know that Manage Shared List Views, new in Summer ‘26, lets users share their own views without Manage Public List Views. (Three permissions)
- I know Salesforce’s Help now suggests the Setup agent for groups and sharing rules, and that what it builds is reviewed like any other sharing change. (Public groups and criteria-based rules)
Beyond the Exam
Section titled “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.
- Name buckets for the access they stand for, not for the people in them today.
- Check a group’s access summary before you change who’s in it.
- Treat the field a rule reads as a security control: who edits it, what fills it, what a blank means.
- Keep guest rules off accounts, contacts and customer data. Build a public-only custom object instead.
- Ask “what about Guam?” before building one rule per value.
- Write the reason in every rule’s description, and name rules as a set.
- Remove rules nobody needs. They still write rows and still recalculate.
- Give the narrowest list view permission that does the job.
Words to Know
Section titled “Words to Know”| Term | In one line |
|---|---|
| Public group | A named list of users, roles, territories and other groups, used as a target for sharing |
| Roles and Internal Subordinates | A role and the internal roles below it, without site or portal users |
| Manager groups | Two groups per user, built from the Manager field, used as sharing targets |
| Personal group | A user’s own group for their manual shares, in Salesforce Classic only |
| Criteria-based sharing rule | A rule that shares records by a field value on the record |
| Source, target, level | What a rule shares, with whom, and how much |
| Guest user sharing rule | A criteria-based rule whose target is a site’s guest user, Read Only |
| Secure guest user record access | The always-on setting that locks guest users down |
| Default owner | The user or queue that owns records guests create |
| Number of zeros | Steve’s way of estimating how many buckets there will be: tens, hundreds, thousands |
| Hard-coded ID | A record ID written into a rule’s criteria, which means nothing in another org |
| Rule sprawl | Rules added for single requests, never removed, until nobody knows why they exist |
| List view | A saved filter and columns that runs as the viewer |
| Manage Shared List Views | The Summer ‘26 permission to share your own list views |
Check Yourself
Section titled “Check Yourself”Short scenarios in the style of the course. Decide your answer before you open it.
1. An admin adds a user to a public group, but the user still sees no new records. Why?
A group grants nothing by itself. The user gets access only to what a rule, a manual share or code shares to that group. Check the group’s access summary to see what it opens. Reread A group is a bucket.
2. Three regions, each with its own role, plus two individual users, need the same records. How many rules?
One. Create a public group with the three roles and the two users, and target it with one rule. Next month, change the group, not the rule. Reread One rule, one group.
3. Performance reviews must reach each employee's managers by the Manager field, not the role hierarchy. What do you use?
Manager groups. Keep the object Private with the hierarchy off, and share each review to the owner’s Managers Group with a sharing rule. Reread Two other kinds of group.
4. A team wants to share cases by a field on the case's account. Can a criteria-based rule do it?
Not directly. A rule reads only fields on the record itself, and not formula fields. Copy the value into a text or number field on the case with an automation, then share on that field. Reread Design the field you share on.
5. A criteria-based rule targets a role, and now it should go to a different role. What do you do?
You can’t change the target after saving. Delete the rule and create a new one, which removes and rewrites its share rows. Next time, target a group. Reread Some choices are final.
6. Records created by high-volume site users must be shared with an internal team. Which rule can do it?
A criteria-based rule, with Include records owned by users who can’t have an assigned role. High-volume users can’t be in owner-based rules. A rule made before Spring ‘22 must be recreated to get the option. Reread Records owned by users without a role.
7. A public site must show product details to visitors who don't log in. What has to be true?
The guest profile must give Read on the object and its fields, and a guest user sharing rule must match the records, Read Only. For Product2, guest rules are the only rules available. Share on an explicit field, and keep customer data out of it. Reread Two locks and Design the criteria for the public.
8. A request: one criteria-based rule per US state, each to its state's group. What's your answer?
Count the buckets. Fifty states fill the 50 on their own, and the next value, Guam, has nowhere to go. If the states go to a few regional teams, fill a region field by automation and write one rule per region, each targeting a group of the region’s state groups. Reread What about Guam? and First, fewer buckets.
9. A rule works in production and in a fresh full sandbox, but matches nothing in a developer sandbox. What's likely wrong?
It matches a record ID. A full sandbox copies records with their IDs, so the rule seems to work; a developer sandbox copies metadata only. Share on a name or a code that’s the same in every org. Reread Why an ID doesn’t travel.
10. A list view "All open cases" is shared with the whole service team. A new agent sees only 12 cases. Is the sharing broken?
No. A shared list view shares the filter, not the records. It runs as each viewer, so each one sees only the records they can already see. Reread What a list view shares.
Explore
Section titled “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.