Account, Opportunity and Case Teams

Module 2 of 6 in the chapter Config-Based Sharing: Manual Shares, Teams and Territories, chapter 9 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: When the people who work a record change from record to record, how do teams share it, and how are account, opportunity and case teams different?

A sharing rule shares a pattern. A manual share shares one record with one person, and nobody else sees why (module 1). Teams sit between the two. Each record carries its own list of people, each with a role and an access level, on a screen everyone can read.

There are three kinds: account teams, opportunity teams and case teams. They seem very similar, but they have their own nuances. Chapter 5, module 4 introduced them. This module goes through what each one can and can’t do.

Account teams

An account team belongs to the people who work the account. Each user can set up a default account team under their own settings: the people who help them work their accounts, each with a team role and an access level for the account and its opportunities, cases and contacts.

Just because I add my team members doesn’t give them access. It’s the button on the account that does it. One button press adds my default team to an account of mine, and now they can see it. It’s like granting manual shares through the team, except the team is on the record, with roles, where people can see it.

Salesforce puts limits on what a team member can get (Considerations for Using Account Teams (opens in a new tab), Salesforce Help, checked 2026-11-07):

• Never less than the default. “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.”
• More than the default needs the owner or above. “Only the account owner or someone higher than them in the direct role hierarchy chain can” grant team members more access than the org-wide default.
• Never more than you have. “You can’t grant team members greater access to child records than you have yourself.” And “Only users with Modify All Data or Modify All Records on Accounts can give a team member more access to related records than the account owner has.”

One more thing to know when you review access. The account team member record shows “only the access level assigned when the ATM record was created.” The Team Member Access action on the account “shows the highest access level that the user has across all access methods” (same page). A team member set to Read Only on opportunities can still have Read/Write from a sharing rule. Look at the action, not just the team record.

Opportunity teams

Opportunity teams work the same way once team selling is enabled. Each user can have a default opportunity team, and on an opportunity you can add members, add the default team, or bring in the account team. That’s a really nice set of administrative screens out of the box.

With Private defaults, the two teams are linked (Considerations and Guidelines for Using Opportunity Teams (opens in a new tab), Salesforce Help, checked 2026-11-07):

• “if you give team members access to an individual opportunity, those users gain read-only access to accounts on the opportunity.”
• “if you remove a user’s access to an individual account, the user is removed from opportunity teams related to the account.”

And three details that surprise people (same page):

• “You can’t create opportunity teams for private opportunities.”
• “Opportunity owners always have full access to their opportunities.” Add an owner to the team at a lower level, and Salesforce restores their full access.
• “When an opportunity is closed and the owner of the opportunity’s parent account changes, opportunity team shares are deleted unless opportunity splits are enabled.”

Case teams

Case teams are different. Account and opportunity teams belong to a user: my default team, your default team. Case teams aren’t user specific. They’re general, predefined teams that anyone can put on a case.

You build them in three steps (Case Teams (opens in a new tab), Salesforce Help, checked 2026-11-07):

1. Case team roles. “Roles determine the level of access to a case, such as read-only or read and write access.”
2. Predefined case teams, “so that users can quickly add people with whom they work.”
3. Assignment rules “that add predefined teams to cases that match specific criteria, such as when cases originate from emails.”

That third step is the powerful one. In case assignment, you can have it automatically assign the team. The case arrives, and the right group of people is already on it, each with the access their role gives.

Two practical notes from the same page. Contacts can be added to case teams, “but they can only access cases when they’re enabled as customer portal users” (chapter 14). And “Each team member on a case counts as 2 KB of storage space”: at millions of cases, teams have a storage cost.

Click to enlarge

When the account changes owner

Teams and owners interact, and the rule for account teams is easy to miss. When the owner changes, you can choose Keep account team. But “If a user with group-based access adds account team members, those team members are removed when the account owner changes, even if you’ve selected Keep account team” (Considerations for Using Account Teams).

To keep team members through an owner change, one of these must have added them (same page):

• A Salesforce admin
• A user with Modify All Data
• The account owner
• “A user higher than the account owner in the owner’s direct role hierarchy chain (not a parallel branch)”

For opportunities, “select Keep Opportunity Team to keep the opportunity team together,” and, when the opportunity’s default is Private and the current owner is on the team, Retain Edit Rights for Previous Owner keeps the old owner’s Read/Write (Considerations and Guidelines for Using Opportunity Teams).

So who adds team members matters, not just who’s on the team. If your automation or your sales operations team adds members, check which of these they are. Module 6 puts every way side by side for an owner change.

Click to enlarge

Supercharge a team with automation

Here’s what I like about teams. You can add team members automatically. In my demo it’s five lines of code: pick the account, pick the user, give them a team role, insert. It could also be a record-triggered flow: when an account is created, find the right user and put them on the account team.

The reason this is powerful: once you’ve added them, the user gets to see it and maintain it. The team is on the record, on the standard screens. Users can see who was added, and why, by role, and even edit or remove them later. So you’re supercharging the out-of-the-box teams with automation and using the standard screens as the admin screens.

Compare that with sharing written by code (chapter 11), where the shares sit in the share table and nobody on the record can see them. If a team can express the access, an automated team is often easier to live with.

Two things to check before you automate. Who is the automation running as, given the owner-change rule above? And “You can’t add high volume portal users to teams” (Considerations for Using Account Teams).

What an architect decides here

• Which objects use teams, and which kind: account and opportunity teams for a user’s own working group, case teams for general teams added by assignment.
• The team roles and their access levels, and who may grant more than the org-wide default.
• Whether users keep their own default teams, or automation fills the teams.
• For automated teams: who the automation runs as, so members survive an owner change, and what removes members when they should go.
• Keep account team, Keep Opportunity Team and Retain Edit Rights for Previous Owner: when they’re used, and by whom.
• Where case teams are added by assignment rules, and their storage at volume.

Beyond the exam: what AI changes. A team shows who works a record, by role, on the record. That makes it a good place for agents to look, and to act: “add the renewal specialist to this account’s team” is one step. Treat an agent that adds team members like any other automation. Decide who it runs as, which roles it may give, and how members it added are removed. And when you review access, use the Team Member Access action: it shows what a person can really do, across every way they got it.

Explore

• Considerations for Using Account Teams (opens in a new tab), Salesforce Help (checked 2026-11-07)
• Considerations and Guidelines for Using Opportunity Teams (opens in a new tab), Salesforce Help (checked 2026-11-07)
• Case Teams (opens in a new tab), Salesforce Help (checked 2026-11-07)