10.2 Service Team Case Management Integrated Lab
Key Takeaways
- A service setup combines support process design, Case fields, queues, assignment rules, escalation rules, Email-to-Case, knowledge, and reports.
- Case automation should route and prioritize work without hiding ownership, entitlements, or exception handling from supervisors.
- Admins must test service features with realistic channels, statuses, users, and case volumes before trusting dashboards or service-level metrics.
- Good service labs include what agents see, what supervisors see, and what breaks when routing, sharing, or required fields are incomplete.
Lab scenario: support team case intake
A customer support team needs Salesforce to manage product questions, billing issues, and urgent outages. The team has six agents, one supervisor, and a shared support email address. Customers may email support, sales reps may create cases from accounts, and supervisors need dashboards for backlog, response age, and priority. The admin must configure enough of Service Cloud behavior to support daily work without overbuilding a full contact center.
Begin with the support process. In Setup > Object Manager > Case > Fields & Relationships, review standard fields before adding new fields. Case already includes Status, Priority, Origin, Type, Reason, Contact, Account, Owner, and Subject. Add a small number of fields only when they drive routing, service commitments, reporting, or resolution. Examples include Product Area, Customer Impact, Root Cause, and Resolution Category. Use restricted picklists where analytics need consistency. Avoid turning Subject or Description into structured data that belongs in a controlled field.
Configure statuses and support process from Setup > Object Manager > Case > Fields & Relationships > Status and Setup > Support Processes. A basic team might use New, Working, Waiting on Customer, Escalated, and Closed. If different teams need different statuses, use record types and support processes, but only after confirming that the added complexity is worth it. Expected observation: agents can move cases through a clear lifecycle and reports can separate active, waiting, escalated, and closed work. Failure mode: too many statuses produce inconsistent use and unreliable backlog reports.
| Service component | Setup path | Expected observation | Failure mode to watch |
|---|---|---|---|
| Case record types and support process | Setup > Object Manager > Case | Agents see statuses and page layouts that match their work | Users choose wrong record type because labels are unclear |
| Queues | Setup > Queues | New cases can wait in Billing Support or Technical Support queues | Cases remain unowned by a person with no supervisor review |
| Assignment rules | Setup > Case Assignment Rules | Email or created cases route by product, type, priority, or account segment | Rule order sends urgent cases to a general queue |
| Escalation rules | Setup > Escalation Rules | Aging or high-priority cases raise visibility | Escalations fire during waiting-on-customer statuses |
| Email-to-Case | Setup > Email-to-Case | Inbound email creates cases with usable origin and contact matching | Duplicate or unmatched contacts create messy case records |
| Service reports | Reports tab | Backlog and aging reports reflect ownership and status | Running user and sharing make supervisor dashboards incomplete |
Create queues before routing. Use Setup > Queues and add Case as a supported object. Build Billing Support, Technical Support, and General Support queues, then add the right users or public groups. Queue membership is not a substitute for training or service ownership. Agents should know when to take ownership, when to transfer, and when to escalate. Expected observation: a new case can be owned by a queue, visible in a queue list view, and accepted by an agent. Failure mode: cases sit in a queue because no one is accountable for triage.
Configure assignment rules in Setup > Case Assignment Rules. Build rules in a deliberate order because Salesforce evaluates entries by sequence. Example: if Priority is High and Product Area is Platform, assign to Technical Support; if Type is Billing, assign to Billing Support; otherwise assign to General Support. Test each rule with sample cases created through the UI and through Email-to-Case if enabled. Include a case with missing Product Area to see the default behavior. The admin should capture rule criteria, owner result, notification behavior, and whether the assigned queue has active members.
Add escalation only after status meaning is stable. In Setup > Escalation Rules, create a rule that escalates high-priority cases after a defined time if they are not Closed and not Waiting on Customer. Escalation can change owner, notify users, or raise visibility, but it should not punish agents for cases that are properly waiting on a customer response. Test business hours, holidays, status changes, and ownership changes. A common failure mode is an escalation rule that keeps firing because nobody defined a clear exit condition.
Set up Email-to-Case in a safe lab context if available. Use Setup > Email-to-Case to review routing addresses and settings, then test with a controlled email account. Expected observations include a new case with Origin Email, subject and description populated, contact matched when the sender email exists, and assignment rules applied if configured. Failure modes include unmatched contacts, case threads splitting because reference information is missing, attachments exceeding limits, or agents replying outside Salesforce and losing activity history.
Build the agent workspace. Use Lightning App Builder and the Service app to make Cases, Accounts, Contacts, Knowledge, Reports, and Dashboards easy to reach. Add list views for My Open Cases, My Escalated Cases, Queue: Billing Support, Queue: Technical Support, and Cases Waiting on Customer. If Knowledge is in scope, enable and configure it in a Trailhead Playground or sandbox, then confirm agents can search approved articles and attach or reference them appropriately. Do not assume Knowledge solves process issues. Articles need ownership, review, and retirement.
Finish with reports that answer operational questions. Create reports for open cases by owner and priority, aged open cases by status, cases created by origin, first response or aging approximations where fields support it, and closed cases by resolution category. Build a supervisor dashboard and verify it as the supervisor. If records are private, the supervisor may need role hierarchy visibility, sharing rules, or team membership. If the dashboard uses a running user, make sure the choice aligns with the intended visibility model.
A manager dashboard that shows all cases because it runs as the admin may hide a sharing gap.
Review prompts before the quiz:
- Which case fields are needed for routing, and which are only nice-to-have labels?
- How should assignment rule order handle urgent cases before general cases?
- Which statuses should pause or exclude escalation timing?
- What happens when an email sender does not match an existing contact?
- How would you prove a supervisor dashboard reflects team backlog accurately?
A high-priority technical outage case is being routed to the general support queue because it also matches a broad default rule. What should the admin review first?
Which case status should usually be considered carefully before triggering aging escalations?
A supervisor dashboard shows no queue backlog, but agents see cases in queue list views. Which area should the admin investigate?