Account Team Member
An Account Team Member is a row on the AccountTeamMember object that grants a Salesforce user access to a specific Account in a named role, separate from ownership.
Definition
An Account Team Member is a row on the AccountTeamMember object that grants a Salesforce user access to a specific Account in a named role, separate from ownership. The Account itself has one owner, but a real sales pursuit usually involves more people: an account executive, a sales engineer, a customer success manager, a technical architect, a renewals rep. Each of those people gets added to the Account Team with a Team Member Role and an Account Access level. The role is a descriptive picklist. The access level is the practical permission, the same Read Only, Read/Write, or Private scale used in standard Account sharing. One Account can have many Team Members. One user can sit on many Account Teams.
Account Teams are the lightweight alternative to writing sharing rules for every cross-functional user. Sharing rules work well for static populations like a region or vertical. They fall apart for dynamic teams where the admin does not know in advance which SE will be on which deal. Account Teams shift that decision down to the rep who owns the Account, who can drag teammates in or out as the pursuit evolves. Default Account Team templates speed this up further: every new Account a user owns automatically inherits their default team, so the standard cast appears on day one.
What Account Teams really do and where they fit
Team Member Role versus Account Access
Team Member Role is a picklist that names what the user does on the Account. Common values are Account Manager, Sales Rep, Solution Engineer, Customer Success Manager, Executive Sponsor. The role is essentially a label. Account Access is the permission level: Read Only, Read/Write, or Private. Most teams give SEs and CSMs Read/Write, while extended audiences like exec sponsors get Read Only. Role and access are independent. You can have ten people in the Sales Rep role, half with Read/Write and half with Read Only. Reporting filters typically slice on role. Sharing impact comes from access.
Default Account Teams and how they propagate
Every user with the right permission can configure a Default Account Team in personal settings. When that user becomes the owner of a new Account, Salesforce auto-adds the default team. Existing Accounts are not back-filled automatically. The owner has to push the team manually through the related list action Add Default Team. The trade-off is intentional: it stops one user's setting change from suddenly granting access across hundreds of legacy records.
Opportunity Team and Case Team are separate objects
There are three team objects in Salesforce, one per parent: AccountTeamMember, OpportunityTeamMember, and CaseTeamMember. They look similar and use similar fields, but membership does not cascade. Putting someone on the Account Team does not give them access to that Account's Opportunities. An Opportunity Team Member row is still needed. Some orgs script automation to keep the three in sync. Others leave them independent to keep the access surface tight.
Sharing implications and the access calculation
The access a user has to an Account is the maximum of ownership, role hierarchy, sharing rules, and Account Team membership. Adding a user to the Account Team can raise their access, never lower it. If the org-wide default for Account is Public Read/Write, the Account Team grant is almost cosmetic. Everyone already has Read/Write. Teams matter most in Private or Public Read Only orgs, where they become the main mechanism for case-by-case access to a single Account.
Enabling the feature
Setup, Feature Settings, Sales, Account Teams, Enable Account Teams. Choose the page layouts on which the Account Team related list appears. Without this step the related list is hidden, even though the underlying objects exist. After enabling, configure Team Member Roles in Setup, Object Manager, Team Role, then add the Account Team component to the Account Lightning record page in App Builder for the cleaner UI.
Account Team and Account Hierarchy
Account Hierarchy uses the ParentId field on Account. It has nothing to do with Account Teams. Sharing does not cascade up or down the Account Hierarchy by default, so adding a user to the team on a parent Account does not give them access to the children. If hierarchy-wide access is the goal, the answer is either hierarchy-aware automation or a broader sharing rule, not the Account Team object.
Reporting on Account Teams
The Account Team Member object has its own report type. Reports on team coverage answer questions like which strategic Accounts lack an assigned SE, or which CSM owns the most ARR. Custom report types that join Account, Account Team Member, and Opportunity are common in revenue operations dashboards. Building one early prevents a flood of ad-hoc requests from sales leadership.
Account Team in Lightning versus Classic
The two UIs treat Account Teams the same at the data level. The Lightning Account Team component is more compact and supports inline editing. Classic shows the related list inline with the legacy look. Migration to Lightning does not affect existing rows; only the visual surface changes. Most orgs replace the standard related list with the Lightning component during their Lightning rollout for the better edit experience.
How to enable and use Account Teams
Enabling Account Teams takes a couple of clicks. Designing the role picklist and deciding defaults takes a conversation with sales leadership.
- Enable Account Teams
Setup, Feature Settings, Sales, Account Teams, Enable Account Teams. Choose the page layouts to which the Account Team related list should be added. The list will not show up on Account record pages until this is done.
- Define Team Member Roles
Setup, Object Manager, Team Role. Create the roles that match how the business actually staffs accounts. A common starting set is Account Executive, Sales Engineer, Customer Success Manager, Solution Architect, Executive Sponsor.
- Add the Account Team component to the Lightning record page
App Builder, edit the Account record page, drop in the Account Team component. The default related list works, but the Lightning component supports inline editing and looks cleaner.
- Train users to configure their default team
Personal Settings, Advanced User Details, Default Account Team. Users add the people they want auto-added to new Accounts they own. Without this step the feature mostly stays unused.
- Stand up role-based reporting
Build a report type that joins Account, Account Team Member, and optionally Opportunity. Coverage gaps and CSM workload reports are usually the first dashboards leadership asks for.
- Adding a user to the Account Team does not give them access to that Account's child Opportunities, Cases, or Contacts unless the corresponding access level fields are set on the same row.
- Default Account Teams only apply to new Accounts the user owns. Existing Accounts must be back-filled manually using Add Default Team on the related list.
- Org-wide defaults of Public Read/Write make Account Teams cosmetic. The feature only matters in Private or Public Read Only orgs.
- Inactive users in a Default Account Team block the auto-add from happening on new Accounts. Audit defaults whenever a sales team is restructured.
Trust & references
Cross-checked against the following references.
- Account TeamsSalesforce Help
- AccountTeamMember API ReferenceSalesforce Developer Docs
Straight from the source - Salesforce's reference material on Account Team Member.
- Set Up Account TeamsSalesforce Help
- Set Up Default Account TeamsSalesforce Help
Hands-on resources to go deeper on Account 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…