Study guide
Study guide for chapter 9 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 one objective from the exam section Access to Records, the biggest section at 39% of the exam: teams. Around it are the other ways you set up without a rule: manual sharing, territories, and Compliant Data Sharing in the industry clouds. The exam guide aligns to Winter ‘23, and some important answers 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.
Manual sharing
- I know manual sharing is for one-off exceptions, and who can do it: the owner, a user above the owner when the object uses hierarchies, Modify All Records, an admin, and a Full Access holder, who can’t grant Full Access. (Who can share)
- I know a manual share can go to users, public groups, roles, roles and internal subordinates, territories and manager groups, and that the access also goes up the hierarchy. (Who it can go to, and how much)
- I know sharing an opportunity, contact or case needs Read on the parent account, and sharing an account caps its children’s access. (The account family)
- I know where it doesn’t work: Experience Cloud sites and the mobile app in Lightning, high-volume users’ records, and guest users. (Where it doesn’t work)
- I know Salesforce’s line of 10,000 manual account shares per recipient, and that a pattern of manual shares wants a rule or a team. (Too many by hand)
- I know manual shares are deleted when the owner changes, by default, including the old account owner’s shares on child records. (When the share goes)
Teams (supports REC-5)
- I know default account teams are added with a button, and the limits: never less than the default, more only from the owner or above, never more than you have. (Account teams)
- I know the Team Member Access action shows a member’s highest access across every way, not just the team record. (Account teams)
- I know under Private defaults an opportunity team member gets read-only access to the account, there are no teams on private opportunities, and owners always keep full access. (Opportunity teams)
- I know case teams are general, predefined teams with case team roles, and assignment rules can add them. (Case teams)
- I know Keep account team keeps only members added by an admin, Modify All Data, the owner, or someone above the owner in the direct chain, and what Keep Opportunity Team and Retain Edit Rights for Previous Owner do. (When the account changes owner)
- I know automation can add team members, so the access shows on the record’s standard screens, and that high-volume portal users can’t be on teams. (Supercharge a team)
Territories
- I know the pieces: territory types and their priority, territories, the territory model and the territory hierarchy, and the limit of 1,000 territories per model, more on request. (The pieces)
- I know a model is Planning, Active or Archived, only one is active, and archiving can’t be undone and deletes territory forecasts and quotas. (One active model at a time)
- I know an account must match all of a territory’s own rules, rules can apply to child territories, and the lowest match on a branch wins. (Which territory gets the account)
- I know territories work on accounts, their opportunities and cases, and leads, not custom objects. (Your own buckets, by automation)
- I know both hierarchies grant upward at once, and the user gets the more generous. (Two paths to the same account)
- I know roles model the reporting structure, territories the sales structure and the matrix, and not to make them identical. (What each hierarchy should model)
- I know territories handle overlays as another branch, and are preferred to teams when the model has them. (Overlays)
- I know writing account assignment rules needs View All Records on Accounts and Manage Territories. (Who runs the territories)
Compliant Data Sharing
- I know it’s only in Financial Services Cloud, Nonprofit Cloud and Public Sector Solutions, with participant roles, participant records, participant groups and Object Enablement Settings. (What it is and The pieces)
- I know a share row is written only when the role gives more than the org-wide default, with the reason Compliant Data Sharing. (When a share row is written)
- I know it adds access but can’t remove any, so the role hierarchy still sees standard objects. (It adds access)
- I know a user who is a participant can’t be deactivated until their participant records are removed. (Limits to design around)
What survives an owner change (supports REC-5)
- I know the three answers: moves with the owner (owner access, the hierarchy, owner-based rules), goes unless you keep it (manual shares, Manual-reason code shares, team members), and stays (criteria-based rules, custom sharing reasons, territories). (Three kinds of answer)
- I know what an account transfer carries automatically, and what only if you select it. (An account carries its family)
- I know an opportunity’s owner change that cascades from its account doesn’t run flows or triggers. (When your automation doesn’t run)
What changed since the exam’s Winter ‘23 alignment (dated, beyond the exam today)
- I know that since Winter ‘27, Keep manual shares when transferring records can keep manual shares on an owner change, for the whole org; it’s off by default. (When the share goes)
- I know custom sharing reasons on standard objects, which Salesforce’s Developers blog said in October 2026 would reach all orgs by the end of that month, so code shares with one survive an owner change. (Goes, unless you keep it)
- I know the feature is now called Sales Territories; Enterprise Territory Management is its older name. (The pieces)
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.
- Look for patterns in manual shares, and replace them with a rule or a team.
- Decide Keep manual shares once, for the org, and tell people which it is.
- Check who adds team members, so Keep account team actually keeps them.
- Prefer an automated team to code sharing when a team can express the access: it shows on the record.
- Build the next territory model in Planning while the current one runs the business, and plan archiving like a data change.
- Test whether changing a rule’s field moves the account, on the screen and through integrations.
- Give each hierarchy its own job, and never make them identical.
- Run the three-user test for every way that changes owners: the screen, mass transfer, integrations and agents.
Words to Know
Section titled “Words to Know”| Term | In one line |
|---|---|
| Manual share | One record shared by hand with a user, group, role or territory |
| Default account team | A user’s own list of people, added to their accounts with one button |
| Team Member Access | The action that shows a member’s highest access across every way |
| Case team role | A role that sets a case team member’s access |
| Keep account team | The owner-change option that keeps qualifying account team members |
| Territory type | A label for organizing territories, with a priority |
| Territory model | A complete territory system; Planning, Active or Archived |
| Account assignment rule | A rule that drops matching accounts into a territory |
| Overlay | A team that works across the main structure, such as key account managers |
| Participant role | In Compliant Data Sharing, a role on an object with an access level |
| Participant record | The junction joining a user or group, a role and a record |
| Sharing reason | The row cause on a share; a custom one survives an owner change |
Check Yourself
Section titled “Check Yourself”Short scenarios in the style of the course. Decide your answer before you open it.
1. A coworker covers one case for a week while its owner is away. What's the simplest way?
A manual share on that case, Read/Write. It’s a one-off exception no rule should cover. Remember the users above the coworker in the hierarchy get it too, and the share goes if the owner changes, by default. Reread Who it can go to, and how much.
2. Users share the same kind of account with the same specialists every week. What do you do?
Replace the pattern. A pattern of manual shares is a sharing model nobody designed. Use a sharing rule or a team. Reread Too many by hand.
3. An account team member's record says Read Only on opportunities, but they can edit them. Why?
The team record shows only the level set when it was created. Another way, such as a sharing rule, gives more. Use the Team Member Access action to see their highest access. Reread Account teams.
4. Cases that arrive by email should go straight to a predefined group of specialists. How?
A predefined case team, with case team roles for the access, added by a case assignment rule. Reread Case teams.
5. An account changes owner with Keep account team selected, and some team members disappear. Why?
They were added by a user with group-based access. Keep account team keeps only members added by an admin, Modify All Data, the owner, or someone above the owner in the direct chain. Reread When the account changes owner.
6. Accounts in San Diego match the rules for San Diego, California and West Coast on the same branch. Where do they land?
San Diego, the lowest matching territory on the branch. If they must also be formally in California, the parent needs its own rule. Reread Which territory gets the account.
7. Someone wants to archive the active territory model to switch to a new one. What do you warn them?
Archiving can’t be undone. Opportunities lose their territory, and territory forecasts, forecast types, quotas and adjustments are deleted. Build and test the new model in Planning first. Reread One active model at a time.
8. Key account managers need certain accounts across every region. The org already uses territories. Where do they go?
Another territory branch, such as a key customers type beside the geographic one. An account can sit in both. If territories can do it, prefer them to teams. Reread Overlays.
9. A bank uses Compliant Data Sharing and wants only assigned advisers to see a client's opportunities. Is that enough?
No. Compliant Data Sharing adds access but can’t remove any, and on standard objects the role hierarchy always grants upward. Salesforce suggests an object with participant-based access, such as financial deals. Reread It adds access.
10. A trigger rebuilds opportunity shares when the owner changes. After an account transfer, its opportunities lose their shares. Why?
An opportunity owner change that cascades from an account owner change doesn’t run flows or triggers. Use a custom sharing reason, which survives the owner change, instead of putting shares back. Reread When your automation doesn’t run.
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.
