Case and Incident Management Configuration
What the exam tests
This domain tests case and incident configuration: case types, statuses, categories, severity, queues, templates, and related records. Expect scenario questions on lifecycle design and the difference between case type and category.
Core rules and concepts
- Case type defines the process: statuses, workflows, assignment, and fields. Category classifies the subject for reporting and routing. Do not overload one with the other.
- Design a small status set with clear transitions; statuses drive SLA clocks and reporting. Retire unused statuses rather than deleting them if history exists.
- Severity and impact are separate: severity is customer or business impact; priority is often derived. Document the matrix.
- Use templates for standard responses and required fields; templates reduce agent effort but must be locale-aware.
- Related records-contacts, assets, service requests, interactions-should be linked through supported relationships, not free-text fields.
Worked example
A warranty claim case type needs intake, diagnosis, approval, and closure. Configure statuses New → Diagnosing → Pending Approval → Resolved → Closed, with a required approval before Resolved. Use a category hierarchy under Warranty, and derive priority from severity plus customer tier. The reasoning: the approval is a process gate, so it belongs in status and workflow; the category supports reporting, not gating.
Traps
- Deleting statuses or categories that existing cases reference.
- Building a deep category tree that agents cannot navigate.
- Using free-text fields instead of relationships for assets and contacts.
- Forgetting that status transitions can trigger SLA milestones and notifications.