Predefined Case Teams
Predefined Case Teams are admin-defined groups of users with specific roles that can be applied as a bundle to any case in one click.
Definition
Predefined Case Teams are admin-defined groups of users with specific roles that can be applied as a bundle to any case in one click. A typical Predefined Case Team for an escalation might include the Tier 2 Engineer, the Account Manager, and the Customer Success Manager, each with a specific Case Team Role determining their access. When the case needs the team, the agent applies the predefined team, and all three users are added at once with the right access. This replaces the manual "add three users one at a time" workflow that slows escalation handling.
Case Teams in Salesforce are the lightweight access-sharing model for ad-hoc collaboration on individual cases. Each Case Team Member has a Case Team Role that defines what they can do on the case: View Only, View and Edit, or full access. Predefined Case Teams package commonly used team compositions for reuse. The pattern is most useful in B2B service environments where escalation paths follow consistent patterns (Tier 1 to Tier 2, account manager loop-in for VIP customers) and adding the right team manually on each case slows the response time.
How Predefined Case Teams streamline case collaboration
Case Teams vs Account Teams: similar concept, different parents
Case Teams and Account Teams are sibling features. Account Teams are configured at the account level and grant access to the parent account's records (opportunities, cases, related lists). Case Teams are configured at the case level and grant access only to the specific case. The two coexist: a customer escalation might add an Account Team for ongoing account ownership and a Case Team for the specific issue's collaborators. Both features support pre-defined patterns: Account Teams have similar default team functionality, and Case Teams have Predefined Case Teams.
Case Team Roles and access levels
Each Case Team Role record defines a named role (Tier 2 Engineer, Account Manager, Solution Architect) and the access level it grants on the case. Access levels: Private (no access beyond the team), Read Only, Read/Write. The role label is what the user sees on the case team panel; the access level is what the platform enforces. Most orgs maintain 5 to 10 Case Team Roles covering the team composition patterns that matter to the business.
Predefined Case Team: the bundle
A Predefined Case Team is a named bundle of users with roles. Setup, Predefined Case Teams, New. Pick the users, assign roles to each, save. The Predefined Case Team becomes available to apply to any case. When applied, the platform adds the users to the case's team with the configured roles. Multiple Predefined Case Teams can exist per org (Tier 2 Escalation Team, VIP Account Team, Legal Review Team), and a single case can have multiple teams applied.
Applying a Predefined Case Team to a case
Agents apply the team from the Case Team related list on the case. Click Add Predefined Team, pick the team from the picker, save. All users in the team are added immediately with their configured roles. Removing the team removes all its members at once. The pattern is what makes the Predefined Case Team valuable: one click handles the team add or remove instead of manual member-by-member work.
Programmatic team application through Flow or Apex
Beyond manual application, Predefined Case Teams can be applied through Flow (using the Add Predefined Case Team action) or Apex (creating CaseTeamMember records programmatically referencing the team). The automated path is useful for escalation rules: a Flow triggered when Case.Priority changes to High automatically applies the Tier 2 Escalation team. The automation eliminates the manual application step and accelerates response time on critical cases.
Sharing implications of Case Team membership
Adding a user to a case team grants them access to the case through the configured role's access level. The access bypasses the case's standard sharing model: a user with no other access to the case can read or edit it through team membership. This is the right model for ad-hoc collaboration but creates audit visibility that the standard sharing model does not. Case Team Member records are queryable through SOQL; built-in reports show who has team-based access to which cases.
Limitations: case-specific only
Predefined Case Teams apply to cases only. They do not grant access to the related Account, Contact, Opportunity, or other records linked to the case. For account-level collaboration, use Account Teams. For opportunity-level, use Opportunity Teams. The Case Team model is intentionally scoped to one case at a time, which is the right design for incident-driven collaboration but limiting when the team needs broader context. Combine with Account Teams when the situation warrants.
Setting up Predefined Case Teams
Configuring Predefined Case Teams is a Setup workflow: define Case Team Roles, build the predefined teams, optionally automate application through Flow.
- Define Case Team Roles
Setup, Case Team Roles, New. Create roles like Tier 2 Engineer, Account Manager, Solution Architect, Legal Reviewer. Set the access level (Read Only or Read/Write) per role.
- Build the Predefined Case Team
Setup, Predefined Case Teams, New. Name the team (Tier 2 Escalation Team), add users, assign roles to each.
- Add the Case Team related list to the case page layout
Setup, Object Manager, Case, Page Layouts. Drag the Case Team related list onto the layout. Without it, agents cannot apply teams.
- Test manual application
Open a test case. From the Case Team related list, click Add Predefined Team, pick the team, save. Confirm the members appear with the right roles.
- Build automation if needed
For automatic application on case criteria (Priority = Critical), build a record-triggered Flow that applies the Predefined Case Team.
- Document the team patterns
Publish a Knowledge Article or training note explaining which team to apply for which case pattern. Without documentation, agents pick the wrong team.
Named role with access level (Read Only or Read/Write). Reused across multiple predefined teams.
Admin-configured bundle of users with roles, applied as a single unit to any case.
Agent-driven add from the Case Team related list. The default usage pattern.
Record-triggered Flow that applies the team based on case criteria. Useful for escalation paths.
The data row tracking each user's role and access on a specific case. Queryable through SOQL.
- Case Teams apply to cases only. They do not grant access to related Accounts, Contacts, or Opportunities. Use Account Teams for broader access.
- Predefined Case Teams cannot be modified per case after application. Adding a different user requires manual addition outside the predefined bundle.
- Case Team access bypasses the standard sharing model. Audit Case Team Member records to confirm the right users have the right access on sensitive cases.
- The Case Team related list must be on the case page layout for manual application. Forgetting it means agents cannot apply teams even when configured.
- Automated application through Flow handles only the addition. Removing the team when the situation changes requires separate logic.
Trust & references
Straight from the source - Salesforce's reference material on Predefined Case Teams.
- Predefined Case TeamsSalesforce Help
- Case Teams OverviewSalesforce Help
- Set Up Case TeamsSalesforce 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 customer experience metric would Predefined Case Teams help improve?
Q2. What business function does Predefined Case Teams primarily support?
Q3. Which Salesforce Cloud includes Predefined Case Teams as a key feature?
Discussion
Loading discussion…