Opportunity Team Member
An Opportunity Team Member is a record on the OpportunityTeamMember standard object that places a single User on the Opportunity Team for one specific deal.
Definition
An Opportunity Team Member is a record on the OpportunityTeamMember standard object that places a single User on the Opportunity Team for one specific deal. Each record links an Opportunity to a User, assigns a Team Member Role from a configurable picklist, and grants that user Read or Edit access to the parent Opportunity. The object is the deal-level counterpart of the Account Team Member, so people can collaborate on one opportunity without inheriting access to every other deal on the same account.
The feature matters most when the Opportunity organization-wide default is Private or Public Read Only. In those orgs, a non-owner needs an explicit grant to view or edit a deal, and an Opportunity Team Member record is one way to provide it. Owners always keep full access to their own opportunities, so team members supplement the owner rather than replace them.
How Opportunity Team Members grant deal-level access
What the OpportunityTeamMember record stores
The OpportunityTeamMember object represents one User sitting on the Opportunity Team of a single Opportunity. The core fields are OpportunityId, which points to the deal, and UserId, the team member being added. TeamMemberRole is a picklist describing what the person does on the deal, with sample values like Account Manager, Sales Rep, Pre-Sales Consultant, and Sales Manager. Administrators control the available roles in Setup, so the picklist reflects how a given company staffs its deals. OpportunityAccessLevel records the sharing the member receives and accepts the case-sensitive values Read or Edit. The Title field can store the person job title for display, and a private note field lets the owner keep context that only the team sees. A photo URL surfaces the member avatar in the related list. Because the object is a junction between a User and an Opportunity, one user can appear on many opportunity teams, and one opportunity can carry many team members. That many-to-many shape is what lets a specialist float across several active deals at once.
Read, Edit, and the OpportunityTeamShare pairing
Adding a team member does two things behind the scenes. Salesforce inserts the OpportunityTeamMember record that names the person and role, and it also creates a matching OpportunityTeamShare row that actually carries the sharing. The OpportunityAccessLevel value on the member record reflects that share. When you insert a member through the API, they start with read access, and you adjust the access by updating the related share. The granted level is always at least equal to the Opportunity organization-wide default. If the default is Public Read/Write, every user can already edit the deal, so a team grant adds no extra access and a Read setting is effectively ignored. The team becomes meaningful when the default is Private or Public Read Only. Giving a team member access to one opportunity in a Private model also grants read-only access to the parent account on that opportunity. This keeps the deal usable, since a rep editing an opportunity usually needs to see the account it belongs to.
Account Teams versus Opportunity Teams
These two features look similar and often confuse new admins, but they cover different scopes. An Account Team Member is attached to an Account and can be configured to grant access to that account child records, including its opportunities, cases, and contracts. An Opportunity Team Member is attached to one Opportunity and grants access to that single deal. Trailhead frames the distinction by time horizon: an account team tends to be a long-term group around a customer relationship, while an opportunity team is a temporary group assembled to close one deal. The two are not mutually exclusive. A practical pattern is to keep the steady relationship managers on the account team, then add deal-specific specialists, such as a solution engineer or a legal reviewer, to the opportunity team only for the deals where they are needed. When the deal closes, that specialist no longer needs visibility into the next opportunity, so opportunity-level grants keep access tightly scoped.
Default Opportunity Teams and automatic population
Salespeople rarely want to rebuild the same supporting cast on every deal by hand. A Default Opportunity Team solves that. Each user configures a default team under their personal settings, listing the coworkers they usually sell with, each one role, and the access each should receive. The user can have that default team added automatically to every new opportunity they own, and can also push it onto existing open opportunities in one action. This is convenient for stable selling pods where the same engineer and manager back every deal. It also has a cost. Automatic population can inflate opportunity team membership quickly across a fast-growing org, which is why reviewing default team setup is a common periodic admin task. Delegated administrators can maintain default teams on other users records, but Salesforce requires at least Read on Account and Opportunity, the Manage Users permission, and a role above the target user in the hierarchy. That guards against a low-privileged admin reshaping a senior rep deal access.
Limits, edge cases, and lifecycle behavior
A few rules shape how teams behave over a deal life. You cannot build an opportunity team on an opportunity whose Private field is selected, since that flag deliberately locks the record to its owner. High-volume portal users cannot be added to opportunity teams at all, so external community access has to come through other sharing. The owner of an opportunity always holds full access regardless of team membership, which means you never need a team record just to give the owner edit rights. Lifecycle events can clean records up for you. When an opportunity is closed and the owner of its parent account changes, the opportunity team shares are deleted unless Opportunity Splits are enabled, since splits depend on those team members staying in place. Deactivating a user also removes the effective access their membership provided, so offboarding usually does not require manually deleting junction records first. These behaviors keep stale access from lingering as deals and people move on.
Reporting and rollups across a selling team
Opportunity teams are not only about access. They also feed visibility and reporting. List view filters such as My Opportunity Teams show the deals a user belongs to as a team member, while My Team Opportunities reflects deals owned by people below the user in the role hierarchy. The two filters answer different questions, so it helps to know which one a report is using. Team members can roll their individual contributions into team-level forecast, quota, and pipeline reporting, which is the point of assembling a team around a large deal in the first place. When more granular credit allocation is needed, Opportunity Splits build on the team by dividing revenue or overlay credit among the named members. In Pipeline Inspection, teams and territories can be used as filters so a manager can review the deals their group is working without scrolling through unrelated opportunities. Treating the opportunity team as the shared roster of who is working a deal keeps both access and reporting aligned.
How to add an Opportunity Team Member
You add an Opportunity Team Member from the Opportunity record itself, through the Opportunity Team related list. Enabling Opportunity Teams in Setup is a prerequisite, and the available roles come from the Team Member Role picklist your admin configures.
- Open the Opportunity Team related list
Go to the opportunity you want to staff and find the Opportunity Team related list on the record page. Click Add to start a new team member, or use Add Default Team to pull in your saved default roster.
- Pick the user and role
Select the User you want on the deal and choose a Team Member Role that describes their part, such as Sales Engineer or Sales Manager. The role list is whatever your administrator defined in Setup.
- Set the opportunity access level
Choose Read or Edit for the member access to this opportunity. Remember the grant cannot fall below the Opportunity organization-wide default, so Read has no effect when the default is already Public Read/Write.
- Save and confirm the share
Save the record. Salesforce stores the OpportunityTeamMember and creates the matching OpportunityTeamShare that carries the access. The member now appears in the related list and can open the deal at the level you set.
The team member being granted access to the opportunity. Stored as UserId on the OpportunityTeamMember record.
The role this person plays on the deal, chosen from the configurable Team Member Role picklist defined in Setup.
Read or Edit access to this opportunity, never lower than the Opportunity organization-wide default.
- You cannot add a team to an opportunity whose Private field is selected; that flag locks the record to its owner.
- High-volume portal users cannot be added to opportunity teams, so plan external access through other sharing.
- A Read grant is silently ignored when the Opportunity organization-wide default is Public Read/Write, because everyone can already edit.
- On a closed opportunity, team shares are deleted if the parent account owner changes, unless Opportunity Splits are enabled.
Prefer this walkthrough as its own page? How to Opportunity Team Member in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Opportunity Team Member.
Hands-on resources to go deeper on Opportunity Team Member.
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.
Discussion
Loading discussion…