Opportunity Team
An Opportunity Team is a group of Salesforce users who share access to a single Opportunity record.
Definition
An Opportunity Team is a group of Salesforce users who share access to a single Opportunity record. Each team member has a defined role (Account Manager, Sales Engineer, Executive Sponsor, Pre-Sales Lead) and a specific access level on the deal. The team is how Salesforce models the fact that one Opportunity is often worked by five or ten people, even though only one user actually owns the record.
Behind the scenes the team lives on the OpportunityTeamMember object, a junction between User and Opportunity. Adding a user to the team creates a row in OpportunityShare with the chosen access level. That share row is what actually grants visibility; the team is the friendlier UI on top of it. Default Opportunity Teams let a rep pre-load the same supporting cast onto every new deal they own, so the Sales Engineer never has to be added manually three times a week.
How Opportunity Teams turn ad-hoc deal sharing into structured access
Why role-based access beats one-off sharing
Without an Opportunity Team, sharing a deal with ten internal stakeholders means ten manual share rows, ten records to revoke when the rep leaves, and zero metadata about who plays what role. The team flips that. You add Maya as Sales Engineer with Read/Write, and the system creates the share, tags the relationship, and lets you report on every deal Maya worked as the SE. The role label is not a free-text string. It feeds Opportunity Splits, the Forecasts hierarchy, and the standard report type that ships with Sales Cloud.
The OpportunityTeamMember object and its shape
OpportunityTeamMember has three fields that matter. TeamMemberRole holds the picklist value (Account Manager, Sales Engineer, Executive Sponsor). OpportunityAccessLevel is the share grant, either Read or Edit. UserId points at the team member. The object is junction-style with cascade-delete on the parent Opportunity, so wiping the deal wipes the team. The OpportunityShare row created underneath has RowCause set to TeamMember, which is what flags it as managed by team membership rather than by manual sharing.
Default Opportunity Teams are per-user, not org-wide
Every user configures their own default team under Personal Settings, Advanced User Details, Default Opportunity Team. The team auto-populates on every Opportunity that user owns. Two gotchas trip people up. Defaults are per-user, so an admin cannot push the same default onto an entire sales team without flow or Apex. And the prompt to update existing open opportunities only applies forward unless the user explicitly checks Update Open Opportunities at save time.
How Opportunity Splits depend on the team
Opportunity Splits live one layer above the team. You cannot split revenue, quota, or overlay credit with a user who is not on the Opportunity Team for that record. The Splits UI silently filters its user picklist to existing team members, which surprises admins who try to add a split for a regional VP who was never added to the team. Add the user to the team first, then build the split.
Partner users and Experience Cloud limits
Customer and Partner Community users can be added to the team, but the access level is capped at Read for most license types. Edit access on the team does not override license-level read-only restrictions on the Opportunity object itself. If you need a partner user to update the deal, the fix is the partner license tier, not the team grant. Some Partner Plus licenses do allow Edit; check the license-capabilities matrix in Setup before promising the access level.
Reporting: the report type still says Sales Team
The label switched from Sales Team to Opportunity Team in the UI years ago, but the standard report type Opportunities with Sales Team kept the legacy name. Reports filtered on team member role pull from this report type. If you build a custom report type called Opportunities with Team Members, it will not include the OpportunityTeamMember object correctly without explicit join configuration in the report type definition.
What teams do not grant access to
Adding a user to the Opportunity Team grants Opportunity access only. It does not grant access to the parent Account, related Contacts, attached Quotes, or the Notes and Files on the Opportunity. Each related object follows its own sharing model. This is the single most common support ticket on the feature: a Sales Engineer added to the team can read the deal but cannot read the Account, because the Account uses a private sharing model with no manual share row.
Setting up Opportunity Teams and default team behaviour
Team selling has to be enabled at the org level before any user can build a team. Once it is on, every user configures their own default team and adds members ad hoc to individual opportunities.
- Enable Team Selling
Setup, Feature Settings, Sales, Team Selling, Opportunity Team Settings. Flip Enable Team Selling on. This adds the Opportunity Team related list to every page layout that already shows the Opportunity object's standard related lists.
- Define Opportunity Team Member roles
Setup, Feature Settings, Sales, Team Roles. The default picklist ships with Account Manager, Sales Engineer, Sales Manager, and Lead Qualifier. Add or rename to match your sales motion. Going past 25 roles makes the picklist unmanageable; consolidate before you add more.
- Configure your default team
Each user does this themselves under their Personal Settings, Advanced User Details, Default Opportunity Team. Add up to ten members, pick a role and access level per row, and choose whether the team auto-applies on Opportunity creation.
- Add members to a specific deal
Open the Opportunity, scroll to the Opportunity Team related list, click New. Pick the user, role, and access level. Save. The OpportunityShare row is created in the same database transaction as the OpportunityTeamMember row.
- Report on team members
Use the standard report type Opportunities with Sales Team. Group by Team Member Role to see deal volume by role, or by User to see workload per person. Add a Closed filter to compare pipeline against won revenue per SE or AM.
Read Only or Read/Write. Read/Write lets the team member edit fields they have field-level access to, but does not grant ownership transfer rights.
When a user edits their default team, this checkbox decides whether the change retroactively populates open deals or only applies to future opportunities.
Customizable. Restricted picklist behaviour applies; users see only the role values you publish in the picklist.
Controls whether the team member's name and role show in the page header as a co-owner card on the Lightning record page.
- Team membership grants Opportunity access only. The parent Account, related Contacts, and child Quotes follow their own sharing rules.
- Default Opportunity Teams are per-user. An admin cannot push the same default to a whole department without flow or Apex.
- Opportunity Splits filter the user picklist to team members. Add the user to the team first or the split UI hides them.
- The legacy Sales Team label still appears on the standard report type even though the feature was renamed Opportunity Team.
- Deleting an Opportunity owner without reassigning first orphans the team; the rows persist but no one can edit them.
Trust & references
Cross-checked against the following references.
- Opportunity Teams OverviewSalesforce Help
- OpportunityTeamMember Object ReferenceSalesforce Developer Docs
Straight from the source - Salesforce's reference material on Opportunity Team.
- Enable Team SellingSalesforce Help
- Set Up Your Default Opportunity TeamSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is an Opportunity Team?
Q2. What does adding someone to a team grant?
Q3. When are Opportunity Teams valuable?
Discussion
Loading discussion…