Account Teams, Opportunity Teams and Manual Sharing
In Salesforce Security and Access, Account Teams, Opportunity Teams, and Manual Sharing are record-level sharing mechanisms that extend access beyond what the organization-wide defaults (OWD), role hierarchy, and sharing rules provide. They are user-driven, exception-based ways to grant access to specific records. Account Teams allow a group of users to collaborate on an account. The team must be enabled by an administrator (Setup > Account Teams), and once enabled, the Account Team related list appears on the account page layout. Each team member is assigned a team role (e.g., Account Manager, Sales Rep) and specific access levels to the account, its related opportunities, cases, and contacts (Read Only or Read/Write). Users can define a default account team in their personal settings and automatically add it to accounts they own. Access granted through the account team is never less than the OWD; it can only widen access. Opportunity Teams work similarly but are specific to opportunities. Enabled under Setup > Opportunity Team Settings, they let the opportunity owner add team members with roles and read-only or read/write access to the opportunity. Opportunity Teams integrate with Opportunity Splits, allowing revenue or overlay credit to be allocated among team members. Users can also define a default opportunity team. Manual Sharing lets a record owner, a user above the owner in the role hierarchy, or a user with Modify All or Full Access share an individual record with another user, public group, role, or role and subordinates. It is available via the Sharing button (which appears only when the OWD for the object is Private or Public Read Only). Manual shares are stored in share tables (e.g., AccountShare) and are removed if record ownership changes. Key exam points: all three only grant additional access, never restrict it; they require appropriate OWD settings to be meaningful; and they are maintained by users rather than automated rules, making them flexible but harder to audit at scale.
Account Teams, Opportunity Teams and Manual Sharing: A Complete Guide for the Salesforce Advanced Administrator Exam
The Advanced Administrator exam dedicates a significant portion of its weighting to Security and Access, and within that domain the examiners love scenarios where the standard sharing model (Org-Wide Defaults, Role Hierarchy, Sharing Rules) is not enough. Account Teams, Opportunity Teams and Manual Sharing are the three tools an administrator reaches for when access must be granted to specific people on specific records, rather than to whole roles or groups. If you understand where each tool sits in the sharing model, who is allowed to use it, what access levels it can grant, and what happens when ownership changes, you will be able to answer almost every question in this area with confidence.
Think of the sharing model as a set of layers that only ever open access, never restrict it:
1. Org-Wide Defaults (the baseline, most restrictive layer)
2. Role Hierarchy (vertical access)
3. Sharing Rules (criteria or owner based, automatic, group-level)
4. Teams and Manual Sharing (record-by-record, user-chosen exceptions)
Teams and manual sharing are the most granular layer, which is exactly why exam writers use them to test whether you know when a sharing rule is overkill and when a team is the right design choice.
Part 1: Account Teams
What an Account Team Is
An Account Team is a group of users who work together on a single account, for example an Account Manager, a Sales Engineer, an Executive Sponsor and a Customer Success Manager. Each team member is given a Team Role and a defined level of access to the account and, optionally, to its related opportunities, cases and contacts. The purpose is twofold: to document who is working on the account and to grant those people the record access they need without writing a sharing rule for every possible combination of people.
How to Enable and Configure It
Account Teams are not enabled by default. The administrator goes to Setup, searches for Account Teams, and enables the feature. During enablement you are prompted to add the Account Team related list to the account page layouts. Key configuration points:
- Team Roles: a picklist that you customise (Account Manager, Channel Manager, Executive Sponsor, Lead Qualifier, Pre-Sales Consultant, Sales Manager, Sales Rep are the defaults). You can add, rename, reorder and replace roles. The Team Role picklist is shared between Account Teams and Opportunity Teams, so a change affects both.
- Access Levels for each member: Account Access (Read Only or Read/Write), Opportunity Access (Private, Read Only or Read/Write), Case Access (Private, Read Only or Read/Write) and Contact Access (only shown when the Contact OWD is not Controlled by Parent).
- Access granted through a team can never be lower than the Org-Wide Default. If accounts are Public Read/Write, the team member field will not let you select Read Only because it would be meaningless.
Who Can Add Team Members
The account owner, any user above the owner in the role hierarchy, administrators, and users with Modify All on Accounts (or Modify All Data) can add, edit or remove account team members. A user who merely has read access through a sharing rule cannot manage the team.
Default Account Teams
Each user can define a Default Account Team in their personal settings (Advanced User Details, then Default Account Team). They choose the colleagues, roles and access levels once, and can tick the option to automatically add the default team to accounts they create or that are transferred to them. On an existing account, the owner can click Add Default Team on the Account Team related list to add their team in one step. This is the answer to any scenario that says a rep always works with the same support people and is tired of adding them manually.
How Access Actually Works Behind the Scenes
When a team member is added, Salesforce writes a record to the AccountTeamMember object and creates corresponding sharing records in AccountShare (and OpportunityShare, CaseShare where applicable) with a Row Cause of Team. Opportunity access granted via the account team applies to all opportunities related to that account, including ones created in the future. The team member does not appear on each Opportunity Team; their access flows from the account level. Because sharing is additive, if a user has Read Only via a sharing rule and Read/Write via the team, they end up with Read/Write.
Ownership Changes and Teams
When an account owner is changed, the user performing the transfer sees checkbox options such as Transfer Open Opportunities Owned By Others, Keep Account Team and Keep Opportunity Team. If Keep Account Team is unticked, the team is removed with the transfer. This is a popular exam point.
Administration at Scale
- Mass Reassign Account Teams (Setup) lets an administrator replace one user with another across many accounts, change roles or remove a person who has left the company.
- Account team members can be loaded with Data Loader through the AccountTeamMember object.
- Report types such as Accounts with Account Team Members allow reporting on who is on which team.
- Disabling Account Teams permanently deletes all existing account team data, so Salesforce warns you first.
Part 2: Opportunity Teams
What an Opportunity Team Is
An Opportunity Team (historically called a Sales Team) is a set of users collaborating on a single deal. It is deal-specific rather than customer-specific. Typical members are the Account Executive, a Solution Engineer, a Partner Manager and a Deal Desk Analyst. Opportunity Teams are also the prerequisite for Opportunity Splits, which divide credit for an opportunity amount or overlay quotas among team members.
Enabling and Configuring
Go to Setup, search Opportunity Team Settings, and enable Team Selling. Add the Opportunity Team related list to opportunity page layouts. The Team Role picklist is the same one used for Account Teams. You can:
- Create custom fields on the Opportunity Team Member object (for example a Commission Percentage or Region field) and edit its page layout.
- Define Default Opportunity Teams in personal settings, with the option to auto-add the team on opportunities a user creates or receives through transfer.
- Enable Opportunity Splits, which depends on Opportunity Teams being active.
Access Levels
Each opportunity team member is given Opportunity Access of either Read Only or Read/Write, and as always the level cannot be below the OWD. Opportunity team membership also gives the member implicit Read access to the parent account, because anyone with access to an opportunity automatically gets read access to the account it belongs to (this is implicit sharing, not a separate team membership).
Who Manages the Team
The opportunity owner, users above the owner in the role hierarchy, administrators and users with Modify All on Opportunities can add, edit or remove members. In Lightning Experience there is also an Add Default Team action.
Relationship Between Account Teams and Opportunity Teams
These are independent structures. Adding someone to an Account Team with Opportunity Access of Read/Write gives them access to the account's opportunities but does not list them on each Opportunity Team. Conversely, adding a user to an Opportunity Team gives them access to that opportunity and implicit read access to the account, but does not place them on the Account Team. Exam scenarios often test whether you can distinguish a request for access to one deal (Opportunity Team) versus ongoing access to every deal for a customer (Account Team with Opportunity Access).
Disabling Opportunity Teams
To turn the feature off you must first disable Opportunity Splits, remove any custom fields and team-related components from layouts and reports, and accept that all opportunity team data will be deleted.
Part 3: Manual Sharing
What Manual Sharing Is
Manual sharing is the ability to grant access to a single record to a specific user, public group, role, role and subordinates, or territory, directly from the record using the Sharing button. It is the ultimate exception mechanism: no configuration, no criteria, just one record shared with one audience. It is available on standard objects such as Accounts, Contacts, Cases, Leads, Opportunities and Campaigns, and on custom objects.
When the Sharing Button Appears
The Sharing button is only meaningful when the Org-Wide Default is more restrictive than the access you want to grant. If an object is Private or Public Read Only, the button appears (in Lightning Experience it must be added to the page layout or is available through the record's action menu depending on release). If the OWD is Public Read/Write there is nothing extra to share, so manual sharing is not offered. Child records in a master-detail relationship are Controlled by Parent and cannot be manually shared independently.
Who Can Manually Share
- The record owner.
- Users above the owner in the role hierarchy (for custom objects, only if Grant Access Using Hierarchies is enabled).
- Users with Full Access to the record, which includes administrators and anyone with Modify All on the object or Modify All Data.
Note that a user who has Read/Write access via a sharing rule or team membership cannot manually share the record further; they need Full Access.
Access Levels and Related Records
Manual shares grant Read Only or Read/Write, never less than the OWD. When you manually share an Account, the dialog also lets you choose access to related Contacts, Opportunities and Cases, mirroring the Account Team behaviour. Manual shares are stored in the object's share table (AccountShare, OpportunityShare, MyObject__Share) with a Row Cause of Manual.
Critical Behaviour: Ownership Changes Delete Manual Shares
When a record is transferred to a new owner, all manual shares on that record are automatically removed. The logic is that the previous owner's decisions about who should see the record no longer apply. This is one of the most frequently tested facts. By contrast, Apex managed sharing (which uses a custom Row Cause) survives owner changes, and team membership can be kept if the transferring user ticks Keep Account Team or Keep Opportunity Team.
Viewing Who Has Access
The Sharing Hierarchy (Lightning) or Sharing Detail page (Classic) lists every user with access to a record and the reason: Owner, Role Hierarchy, Sharing Rule, Team, Manual Share, Territory and so on. When a question asks how an administrator can find out why a particular user can see a record, this page is the answer.
Part 4: Choosing the Right Tool
Use this quick decision guide when reading a scenario:
- Access must be granted automatically to everyone in a role, group or territory, based on owner or field values: Sharing Rule.
- A named group of people needs ongoing access to a customer and all its related deals and cases, and you want to document their roles: Account Team.
- Specific people need access to one deal, or you need to split revenue credit: Opportunity Team.
- A one-off exception on a single record, possibly to a public group or role: Manual Sharing.
- Access logic is too complex for any declarative tool and must survive owner changes: Apex Managed Sharing.
- A rep always works with the same colleagues and wants them added without effort: Default Account Team or Default Opportunity Team.
- An employee left and must be removed from hundreds of account teams: Mass Reassign Account Teams.
Exam Tips: Answering Questions on Account Teams, Opportunity Teams and Manual Sharing
Tip 1: Always start from the Org-Wide Default. Teams and manual sharing only open access upward. If a scenario says the object is Public Read/Write and asks how to restrict a team member, the answer is to tighten the OWD, not to use a team. If the OWD is already Public Read/Write, the Sharing button will not even appear.
Tip 2: Know exactly who can share or add team members. Owner, users above the owner in the role hierarchy, and users with Full Access (Modify All or Modify All Data). A user with Read/Write via a sharing rule is not enough. If an answer option says a colleague with edit access can manually share the record, it is a distractor.
Tip 3: Ownership change is the classic trap. Manual shares are deleted when the owner changes. Account and Opportunity Teams are kept only if the Keep Team options are selected during transfer. Apex managed shares are retained. Memorise these three outcomes.
Tip 4: Account Team versus Opportunity Team. If the scenario is about a customer relationship across many opportunities and cases, choose Account Team and set the Opportunity and Case access levels. If it is about one deal or involves splitting revenue credit, choose Opportunity Team. Remember Opportunity Splits require Opportunity Teams to be enabled first.
Tip 5: The Team Role picklist is shared. If a question mentions changing team roles for account teams and asks what else is affected, the answer is opportunity teams.
Tip 6: Default teams solve repetitive work. Any wording like 'the same three people every time' or 'without manually adding them to every record' points to Default Account Team or Default Opportunity Team with the auto-add option.
Tip 7: Access via Account Team to opportunities is automatic and future-proof. A member with Opportunity Access of Read/Write on the account team sees all current and future opportunities on that account without being on each Opportunity Team.
Tip 8: Implicit sharing is real. Opportunity team members (and anyone with opportunity access) get implicit Read access to the parent account. Do not pick an answer that says a separate manual share on the account is required just so they can view it.
Tip 9: Use the Sharing Hierarchy to troubleshoot. When asked how to determine why a user can or cannot see a record, the Sharing button or Sharing Hierarchy showing the reason for access is the correct choice, not a report or a login as user.
Tip 10: Enabling and disabling have consequences. Enabling teams requires adding related lists to layouts; disabling teams deletes all team data; disabling Opportunity Teams requires disabling Opportunity Splits first. Questions about 'what must be done first' usually hinge on these dependencies.
Tip 11: Watch for scale clues. Hundreds or thousands of records with the same sharing need indicates a sharing rule or Mass Reassign Account Teams, never one-by-one manual sharing. The exam rewards choosing the most maintainable option.
Tip 12: Manual sharing targets. You can manually share with users, public groups, roles, roles and subordinates, and territories. You cannot manually share with a profile or a permission set. Eliminate any answer that suggests sharing a record with a profile.
Tip 13: Master-detail children cannot be manually shared. Their access is Controlled by Parent, so share the parent record instead.
Tip 14: Read every option for the words 'lower' or 'restrict'. No team or manual share can ever grant less access than the OWD or remove access granted elsewhere. Sharing is additive; the most permissive grant wins.
Summary
Account Teams give named users role-labelled, configurable access to an account and its related opportunities, cases and contacts, with default teams and mass reassignment for efficiency. Opportunity Teams give named users access to a single deal, enable Opportunity Splits and provide implicit read access to the parent account. Manual Sharing is the record-level exception tool, available to owners, their superiors in the hierarchy and users with Full Access, and its shares disappear when the record changes owner. Master the enablement steps, the access levels, the permission to manage each mechanism, and the ownership-change behaviour, and you will be well prepared for every question the Advanced Administrator exam asks in this area.
Admin II - Account Teams, Opportunity Teams and Manual Sharing Example Questions
Test your knowledge of Account Teams, Opportunity Teams and Manual Sharing
Question 1
At Universal Containers, the Account org-wide default is Private and the Contact org-wide default is Controlled by Parent. A sales rep who owns an account wants to give a colleague access to one key contact on that account. The Sharing button appears on the account record but is missing on the contact record. What explains this behavior?
Question 2
At Cloud Kicks, the Opportunity org-wide default is Private. Overlay specialists join individual deals and must be able to edit only the deals they work on. Finance also wants revenue credit divided among everyone who worked each deal. One administrator proposes account teams. Another proposes manual sharing on each opportunity. Which recommendation best meets every requirement?
Question 3
At Universal Containers, the org-wide default for Account is Private. Sales reps currently use manual sharing to give a product specialist edit access to the specific accounts each rep selects. Every quarter, a realignment reassigns many accounts to new owners, and the specialists then lose access to those accounts. The rep-selected access must continue after each reassignment, and specialists must not gain access to accounts no rep has chosen. What should the administrator do?