Salesforce teams are groups of users who collaborate on specific records. Account Teams manage customer relationships, Opportunity Teams close deals, and Case Teams handle service requests. Each team type grants record-level access based on team roles, but they’re limited to their designated objects: Account, Opportunity, and Case respectively.
What Are Salesforce Teams and How Do They Work?
Salesforce provides native team functionality that allows multiple users to collaborate on the same record without duplicating data. The platform offers three distinct team types, each designed for a specific business context:
- Account Teams: Long-term collaboration on customer accounts
- Opportunity Teams: Deal-focused collaboration for sales
- Case Teams: Service request collaboration for support
All three team types share a common architecture: a Team Roles picklist that defines each member’s function, and configurable access levels that control what team members can see and do. When you add someone to a team, they receive the access level defined by their role, automatically.
Shared Team Roles
The Team Role picklist is shared across Account Teams, Opportunity Teams, and Case Teams. Choose role names that work across all three contexts, or customize per object if your organization has distinct needs.
Across implementations, I’ve found that Team Role names work best when they describe the function, not the job title. Roles like “Technical Lead” or “Executive Sponsor” translate across Account, Opportunity, and Case Teams without confusion. The orgs that use job titles (“Senior Sales Engineer II”) end up with dozens of roles that mean the same thing. Keep the list short. Five to eight roles usually covers most scenarios.
How Do Account Teams Enable Collaboration?
An Account Team is a group of users collaborating on a single account. Unlike standard ownership where one user owns the record, Account Teams enable multiple stakeholders to work together while maintaining clear access boundaries.
What Account Teams Provide
According to Salesforce documentation, Account Teams grant record-level access not just to the Account, but optionally to related:
- Opportunities
- Contacts
- Cases
Each team member receives one of three access levels, as outlined in SalesforceBen’s Account Teams best practices guide:
| Access Level | Account | Opportunities | Contacts | Cases |
|---|---|---|---|---|
| Read Only | View | View | View | View |
| Read/Write | Edit | Edit | Edit | Edit |
| Private | None | None | None | None |
Important Limitation
An Account Team cannot own an account. Team members still require object-level access via profiles or permission sets. The team only grants record-level access.
Default Account Teams
As noted in SalesforceBen’s guide, users can establish a Default Account Team under My Settings → Advanced User Details. This predefined team automatically populates when the user creates or is assigned to relevant accounts, reducing repetitive manual entry.
When to Use Account Teams
Account Teams work well when:
- Multiple users need ongoing access to specific accounts
- You want to report on team composition and roles
- Manual, one-off record sharing is acceptable
- You’re approaching criteria-based sharing rule limits (50 on Account)
The pattern I see most often: regional and enterprise sales teams that need visibility into each other’s accounts but don’t share a reporting line. Role hierarchy can’t solve it without restructuring the org chart. Account Teams let the account owner grant access directly, no admin involvement, no new sharing rules. It’s particularly useful when orgs are close to their sharing rule limits and need a lighter-weight option.
When Should You Use Opportunity Teams?
Opportunity Teams serve a different purpose than Account Teams. As explained in SalesforceBen’s Opportunity Teams guide, while Account Teams support long-term customer relationships, Opportunity Teams are temporary groups focused on closing specific deals.
The OpportunityTeamMember Object
According to Salesforce’s team selling documentation, every Opportunity Team member is represented by an OpportunityTeamMember record linking:
- The user
- The opportunity
- Their team role
- Their access level
This structure enables reporting on deal collaboration patterns, identifying which roles contribute most to closed-won opportunities.
Key Differences from Account Teams
| Aspect | Account Teams | Opportunity Teams |
|---|---|---|
| Duration | Long-term | Deal-specific |
| Focus | Customer relationship | Closing the deal |
| Scope | Account + related records | Single opportunity |
| Persistence | Remains until removed | Often ends at close |
Big Deal Alerts
As highlighted in SalesforceBen’s Opportunity Teams article, Salesforce includes built-in notification capabilities for Opportunity Teams through Big Deal Alerts (email notifications triggered when opportunities reach defined amount and probability thresholds). For more flexible automation, consider record-triggered flows with email alerts targeting specific team member roles.
Default Opportunity Teams
Similar to Account Teams, users can configure Default Opportunity Teams that automatically assign colleagues to new opportunities, streamlining team formation for consistent deal structures.
Most orgs I’ve worked with automate Opportunity Team membership based on deal stage or opportunity attributes. The typical pattern: when an opportunity reaches a certain stage, a flow adds the relevant specialist (solution engineer, legal reviewer, implementation lead) to the team automatically. The part that often gets missed: handling cases where the lookup field is empty. Without that check, the flow fails silently and nobody gets added.
What Role Do Case Teams Play in Service?
According to Salesforce’s Case Teams documentation, Case Teams enable collaboration on service requests, following the same pattern as Account and Opportunity Teams but focused on support scenarios.
Service-Focused Collaboration
Case Teams are particularly useful when:
- Multiple support agents need visibility into a case
- Escalations require specialist involvement
- Cross-functional teams handle complex service requests
- Compliance requires documented collaboration
Case team members receive access based on their assigned role, with configurable read or read/write permissions on the case record.
Integration with Service Cloud
Case Teams integrate with Service Cloud workflows, enabling assignment rules and escalation processes to automatically populate team membership based on case attributes like priority, product, or customer tier.
Automation Consideration
Use record-triggered flows to automatically add Case Team members when specific criteria are met, such as adding a technical specialist when the case type indicates a complex product issue.
What Are the Limitations of Standard Salesforce Teams?
Standard Salesforce teams work well for basic collaboration scenarios, but they have architectural constraints that become apparent in complex organizations.
Object-Specific Restrictions
The most significant limitation: each team type only works with its designated object.
| Team Type | Supported Object | Custom Objects |
|---|---|---|
| Account Team | Account only | Not supported |
| Opportunity Team | Opportunity only | Not supported |
| Case Team | Case only | Not supported |
If your organization needs team-based collaboration on custom objects (like Projects, Engagements, or custom relationship objects), standard teams cannot help.
Admin Dependency
Standard team setup requires administrator involvement:
- Enabling team functionality in Setup
- Configuring Team Role picklist values
- Adding related lists to page layouts
- Setting up sharing rules for team access
Business users cannot create or modify team structures without admin support.
No Cascading to Custom Objects
Account Teams can optionally grant access to Opportunities, Contacts, and Cases, but not to custom objects related to the account. If you have custom child objects that need team-based access, you must implement separate sharing rules or manual sharing.
Sharing Rule Complexity at Scale
Large organizations often hit sharing rule limits or experience query performance issues when teams and sharing rules multiply. Each Account has a 50 criteria-based sharing rule limit, which teams can quickly consume in complex org structures.
In larger orgs, I’ve seen list view and report performance degrade once sharing rules multiply. The pattern is usually the same: each department adds rules for their use case, nobody reviews the cumulative impact, and eventually queries slow down. The orgs that avoid this problem tend to audit sharing rules quarterly and consolidate where criteria overlap. It’s not glamorous work, but it prevents the “why is Salesforce so slow” conversations later.
Key Takeaways
- Account Teams for relationships, Opportunity Teams for deals, Case Teams for service: each standard team type serves a specific business context
- Standard teams grant record access based on roles but are limited to Account, Opportunity, and Case objects
- Default Teams reduce repetitive setup by automatically populating team membership when users create or are assigned records
- Standard teams require admin involvement for initial setup and configuration, though day-to-day membership changes can be user-managed
- Custom objects require alternative approaches: standard teams only work with their designated objects (Account, Opportunity, Case)
Sources
- Salesforce Help: Team Selling: Official documentation on Account and Opportunity Teams
- Salesforce Help: Case Teams: Official documentation on Case Teams
- SalesforceBen: Best Practices for Using Salesforce Account Teams: Comprehensive guide on Account Team configuration
- SalesforceBen: Salesforce Opportunity Teams: Deep dive into Opportunity Team functionality
Related Articles
Written by
Artur Kolasa
Senior Architect | Salesforce CTA
Salesforce Certified Technical Architect (CTA). Deep background in enterprise Salesforce architecture. Every solution we build is designed or reviewed by a CTA.