Skip to content

Config-Based Sharing: Manual Shares, Teams and Territories

Chapter 9 of Securing Salesforce: Sharing and Visibility, Part 2: The File Cabinets: Sharing Records. New to the course? Start with chapter 1.

Chapters 7 and 8 opened records by rule: every record that matches, every record a team owns. But some needs aren’t a pattern. A coworker is covering a case while its owner is away. A specialist needs one opportunity for a week. The people who work an account change from account to account. And some companies have thousands of sales buckets, far past what rules can hold.

This chapter is the ways you set up without writing a rule: a manual share for one record, a team on each record, territories for accounts by region or segment, and, in the industry clouds, Compliant Data Sharing. Then it asks the question a student once asked me that I couldn’t answer on the spot: when the record changes owner, which of these survive?

  • A manual share is a one-off exception. One record, shared by hand, that no design document lists, and it goes when the owner changes, by default.
  • Teams sit between rules and manual shares. Each record carries its own list of people, each with a role and an access level, on a screen everyone can read.
  • Three kinds of team, three sets of nuances. Account, opportunity and case teams each work a little differently.
  • Territories are buckets that scale. Up to 1,000 per model, more on request, but they work on accounts.
  • Two hierarchies, one account. Roles and territories both grant upward, at the same time; give each its own job.
  • Compliant Data Sharing adds access by role, with roles a compliance team controls, in Financial Services Cloud, Nonprofit Cloud and Public Sector Solutions.
  • Every way gets one of three answers on an owner change: it moves with the owner, it goes unless you keep it, or it stays.
  • Test it with three users: the old owner, the new owner, and the person who should keep or lose access.

Here’s the chapter’s biggest idea: two hierarchies granting the same account.

Two hierarchies, one account Two hierarchies, one account, side by side. The role hierarchy: a sales VP, a regional manager under them, and a rep under the manager who owns an account in San Diego; the rep, the manager and the VP see it. The territory hierarchy: West Coast, California under it, and San Diego under California, which holds the same account; the users in San Diego, California and West Coast see it too. Footnote: both hierarchies grant access upward, at the same time; the user gets the more generous. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.57.1", "built": "2026-11-01", "id": "DGM-SVA-TT-07", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "tree 0.1.0", "theme": "stevetecharc 1.4.0"} Sales VP role hierarchy sees it Regional manager sees it A rep the account is in San Diego sees it owns the account West Coast territory hierarchy sees it California sees it San Diego holds the account sees it Both hierarchies grant access upward, at the same time. The user gets the more generous. HOW TO READ IT rolls up: every role on the path sees what is below it owns the record © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

And the question every one of these ways has to answer.

What survives an owner change What survives an owner change. Moves with the owner: the new owner's full access; the role hierarchy above the new owner, while the managers above the old owner lose access; owner-based sharing rules, re-evaluated; the account owner's access to the account's contacts, opportunities and cases, set by the owner's role. Goes, unless you keep it: manual shares, kept only if Keep manual shares when transferring records is on; Apex or flow shares with the Manual sharing reason, the same rule; account team members, kept with Keep account team only if the owner, someone above them or an admin added them; opportunity team members, kept with Keep Opportunity Team. Stays: criteria-based sharing rules, unless they read the owner; shares with a custom sharing reason; territory assignment, which follows the account's fields and the rules. Footnote: test it with three users: the old owner, the new owner, and the person who should keep or lose access. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.57.1", "built": "2026-11-03", "id": "DGM-SVA-TT-11", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison 0.5.0", "theme": "stevetecharc 1.4.0"} Moves with the owner it was about the owner The new owner's full access The role hierarchy above the new owner Owner-based rules, re-evaluated The owner's access to the account's children Goes, unless you keep it deleted by default Manual shares: keep with the org setting Apex or flow shares with the Manual reason Account team: Keep account team; who added them matters Opportunity team: Keep Opportunity Team Stays never about the owner Criteria-based rules, unless they read the owner Shares with a custom sharing reason Territory assignment Test it with three users: the old owner, the new owner, and the person who should keep or lose access. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Six modules, each standing on its own.

  1. Manual Sharing: One Record, Shared by Hand. Who can share; who it can go to, and how much; the account family; where it doesn’t work; too many by hand; when the share goes.
  2. Teams: Account, Opportunity and Case Teams. Account teams; opportunity teams; case teams; when the account changes owner; supercharging a team with automation.
  3. Sales Territories: Models, Types and Assignment Rules. The pieces; one active model at a time; which territory gets the account; when the rules run; users in territories and what they get; your own buckets, by automation.
  4. Two Hierarchies, One Account: Territories and Roles Together. Two paths to the same account; what each hierarchy should model; overlays; who runs the territories.
  5. Compliant Data Sharing: Participants, Roles and Groups. What it is; the pieces; when a share row is written; it adds access and can’t take any away; limits; teams or Compliant Data Sharing.
  6. What Survives an Owner Change: Every Way Side by Side. Three kinds of answer; what moves, goes and stays; an account carries its family; when your automation doesn’t run; the three-user test.

Then check what stuck with the study guide.

  • Who may share by hand, where manual shares are becoming a pattern, and who reviews them.
  • Which objects use teams, which kind, the team roles and their access, and whether automation fills them and who it runs as.
  • Whether accounts need territories at all, and if so the types, the model lifecycle and the assignment rules.
  • What each hierarchy models: roles for the reporting structure, territories for the sales structure, never identical.
  • In an industry cloud, whether Compliant Data Sharing replaces teams, and who owns its participant roles.
  • For every way the org shares a record, what happens on an owner change, and whether Keep manual shares, Keep account team and Keep Opportunity Team are used.
  • The three-user test for every way that changes owners: the screen, mass transfer, integrations and agents.

Beyond the exam: what AI changes. Every way in this chapter is something an agent can do in one step: share a record by hand, add someone to a team, change the field a territory rule reads, reassign a record. None of it shows up in a design document. If agents can do these things, decide who they act for, what they may share and give, and how you’ll find what they did. And before an agent transfers records, know which shares go with the old owner. Chapter 20 covers agents.

Each module lists its own sources. Two to start with:

Next: Overrides and Implicit Sharing: What You Get for Free