Manual, Teams, Territories and More

Module 4 of 9 in the chapter Steve’s 25 Ways to Share a Record: The Map, chapter 5 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: When a rule can’t say who needs a record, how do people open it themselves, one record at a time, and what happens to that access later?

Set 2 opened records by rule. Set 3 is the ways people open them by hand, typically through the screens: share this one record, add someone to this account’s team, put this account in a territory, add a participant to a client’s record, share your calendar. Five ways: manual sharing, teams, territories, Compliant Data Sharing and calendar sharing.

They look like the simple ones. They’re not always. Each has its own nuances, and the first one has just changed.

Click to enlarge

Way 8: manual sharing

Manual sharing is where a particular record has an owner, and that owner grants access to a specific other user. Salesforce: “Manual sharing allows users to share individual records with other users, public groups, and roles.” It’s for “one-off access exceptions, when sharing rules or other features can’t be used to grant the intended access” (Manual Sharing (opens in a new tab), Salesforce Help, checked 2026-11-01).

Who can share? The record owner; a user in a role above the owner, if the object grants access using hierarchies; a user with Modify All Records on the object; or an admin (same page).

In class, I show it in Workbench. The account share table has 26 rows. I open a record, click Sharing, share it with Paul the pilot, Read Only, and save. Run the query again: 27, and there’s a manual share for Paul. Delete the share, run it again: 26. That’s all a manual share is: one row.

The owner changes: what happens to manual shares

For years, the rule I taught was simple: change the owner, and all the manual shares are wiped. You start fresh. That’s still the default. But it’s no longer the only choice.

Winter ‘27 added a setting. The release note: “Previously, when a record owner changed, Salesforce deleted the manual shares on the record.” Now you can “choose whether to retain these manual shares when the record is transferred to a new owner.” It’s an org-level setting on the Sharing Settings page, “disabled by default to preserve the prior behavior” (Winter ‘27 release notes: Permissions and Sharing (opens in a new tab), Salesforce, checked 2026-11-01). Salesforce Help names it “Keep manual shares when transferring records” (Manual Sharing).

So ask a new question in every design: when this record changes owner, should the people the old owner shared with keep it? Before Winter ‘27 there was no question to ask. Now it’s a decision, and it applies to the whole org.

Way 9: teams

There are three kinds of team: account teams, opportunity teams and case teams. They look similar, but they act differently and they have different purposes.

Account teams and opportunity teams belong to a user. I set up my default account team: the people who help me work my accounts, each with a team role and an access level. Just setting up my default team doesn’t give them access. Then on an account of mine, one button adds my default team, and now they can see the account. Opportunity teams work the same way once team selling is on, and an opportunity can bring in the account team too.

Salesforce’s limit on what a team can give: “Team member access must be equal to or less restrictive than the org-wide default. You can grant team members more access than the default, but not less.” And “You can’t add high volume portal users to teams” (Considerations for Using Account Teams (opens in a new tab), Salesforce Help, checked 2026-11-01).

Case teams are different animals. They aren’t a user’s team. You create case team roles, which set the access, and predefined case teams, which anyone can use. And you can “Create assignment rules that add predefined teams to cases that match specific criteria” (Case Teams (opens in a new tab), Salesforce Help, checked 2026-11-01). It’s not like a queue. In a queue, people see the case until someone takes it. A case team stays on the case and works it together.

Supercharge a team with automation

Here’s what I like about teams. With a few lines of code, or a flow, you can add a team member automatically: when an account is created, find the right user and put them on the account team. In my demo it’s five lines.

Why not just write a share in code? Because the team comes with screens. The user can see who’s been added, and edit or remove them later. That’s the good and the bad: the users will see these team members, and they can remove them. If you want a first draft of sharing that people can then manage themselves, it’s great. If nobody may ever remove it, that’s Set 5.

Way 10: territories

Territories are a Swiss Army knife for accounts. Salesforce calls the feature Sales Territories today; you’ll also see its older name, Enterprise Territory Management. You “Create territory types, build a model, and then add and test your account assignment rules,” then “assign accounts, leads, and users” (Sales Territories (opens in a new tab), Salesforce Help, checked 2026-11-01).

The idea is buckets. You put accounts in a territory, you put users in the territory, and the users can see those accounts. The territory decides how much they get on the account and its opportunities and cases. That access is independent of the role hierarchy, criteria and owners.

Territories can be geographic, Arizona and California under a West Coast, or not geographic at all, like gold, silver and bronze customers. Assignment rules drop accounts in: if the billing state is AZ, put it in Arizona. You can even add your own custom field and a rule on it, to build your own model of buckets alongside the geographic one. Watch when the rules run, though: in my demo they fired when the account was created, and a later change to the field needed the rules run again.

Here’s why they matter for sharing. Owner-based sharing rules give you 300 buckets. Territories give you far more: “Allocations for each territory model include up to 1,000 territories,” and Salesforce Customer Support can increase that, up to 99,999 per model on some editions; “Requests for more than 20,000 territories per model are subject to approval” (Allocations and Considerations for Territories (opens in a new tab), Salesforce Help, checked 2026-11-01).

The catch: territories are about accounts. If you’re talking about a custom object, territories go out the window. And the same trick as teams works here: an automation can put accounts in territories and users in territories. Instead of programmatic sharing, you can have programmatic territory assignment.

Way 11: Compliant Data Sharing

This one you’ll only meet in the industry clouds, such as Agentforce Financial Services. A user is added to a record as a participant, with a participant role. Salesforce’s Trailhead explains it: “the system creates a junction object that connects the user, the participant role, and the specific shared record. Compliant Data Sharing can then grant the user access to the record, even if it’s beyond what’s given by org-wide defaults” (Compliant Data Sharing in Financial Services Explained (opens in a new tab), Trailhead, checked 2026-11-01).

It belongs in this set because, like a team, it’s people added to one record. It’s licensed, so check your org has it before you design with it. Chapter 9 goes further.

Way 12: calendar sharing

The smallest way on the map, and the one people forget. A user can share their own calendar with a coworker, at four levels: Hide Details, Hide Details and Add Events, Show Details, and Show Details and Add Events. Admins set org-wide calendar sharing levels, but “Admins can’t give coworkers access to event details” (Share Your Calendar in Lightning Experience (opens in a new tab), Salesforce Help, checked 2026-11-01).

So the user decides who sees what’s on their calendar. It’s about events, nothing else, but in a review someone will ask how a coworker saw a meeting’s details. This is how. Chapter 12 covers it with the other data.

The share table: rows people add

The share table keeps growing. In my class org, I query the account share table and see owner shares, a territory share, two team shares, and then I add a manual share. On AccountShare, these rows have their own row causes: Manual, Team for an account team, and Territory (AccountShare (opens in a new tab), Object Reference, Winter ‘27, checked 2026-11-01).

Each row says why it’s there, so each one behaves differently. A manual row goes when the owner changes, unless you’ve turned on keeping it. A team row follows the team. A territory row follows the territory.

Click to enlarge

Where this goes deep

Chapter 9, Config-Based Sharing: Manual Shares, Teams and Territories, takes these apart: who can share, keeping manual shares on transfer, team design and automation, territory models and assignment, and Compliant Data Sharing. Calendar sharing is in chapter 12. For now, know the five, and know which of them people can change themselves.

What an architect decides here

• Whether manual shares are kept when records change owner, for the whole org, now that it’s a choice.
• Which objects use teams, the team roles and their access, and whether an automation adds members.
• Whether users may remove the people an automation added, and if not, that it belongs in Set 5 instead.
• For accounts, whether territories are the right buckets, and how many there will be.
• Whether an industry cloud’s Compliant Data Sharing is licensed and used.
• The org-wide calendar sharing levels.

Beyond the exam: what AI changes. An agent can be asked to share a record, add a team member or move an account to a territory, through the same screens and actions a person uses. Each of those is a sharing decision. Decide which of them an agent may make, and make sure each one leaves a row that says who did it and why. Chapter 20 covers agents.

Explore

• Manual Sharing (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Winter ‘27 release notes: Permissions and Sharing (opens in a new tab), Salesforce (checked 2026-11-01)
• Considerations for Using Account Teams (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Case Teams (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Sales Territories (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Allocations and Considerations for Territories (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Compliant Data Sharing in Financial Services Explained (opens in a new tab), Trailhead (checked 2026-11-01)
• Share Your Calendar in Lightning Experience (opens in a new tab), Salesforce Help (checked 2026-11-01)
• AccountShare (opens in a new tab), Object Reference (checked 2026-11-01)