Case management deep dive in Dynamics 365 Customer Service

The case is the fundamental record in Dynamics 365 Customer Service. Every inbound issue — by email, chat, phone, social — typically becomes a case, lives a lifecycle of investigation and resolution, and contributes to service KPIs. Understanding the case model's nuances unlocks operational discipline.

Case anatomy. A case captures:

• Title — short description.
• Customer — the account or contact reporting.
• Status — Active, Resolved, Cancelled (each with finer reasons).
• Origin — channel (email, phone, web, chat).
• Priority — low/normal/high/urgent.
• Severity — impact level.
• Subject — the case type, often hierarchical.
• Owner — agent or queue.
• Created on / Resolved by date — for SLA calculations.
• Resolution — narrative of how it was resolved.

Case statuses and status reasons. Each main status has secondary status reasons:

• Active: In Progress, On Hold, Waiting for Details, Researching.
• Resolved: Problem Solved, Information Provided.
• Cancelled: Cancelled, Merged.

The status reasons are configurable; they're the granular reporting axis. "Closed cases" is interesting but "closed cases by reason" reveals operational patterns.

Subject hierarchy. Subjects are a hierarchical taxonomy (Subject table). Used for:

• Categorisation — "Billing → Invoice Dispute → Wrong Address."
• Routing — cases in a subject branch route to specific queues.
• Reporting — what subjects generate volume?

Good subject design is a piece of structural work — too shallow (just top categories) loses information; too deep, agents pick wrong categories.

Parent / child cases. Cases can be related hierarchically:

• Parent case — the umbrella issue.
• Child cases — individual customer reports of the same problem.

Useful for major incidents (production outage affecting 50 customers) — one parent case tracks resolution, child cases preserve individual customer history. Parent resolution can cascade to children.

Merge cases. Two cases for the same issue from the same customer:

• Merge collapses into one; the merged-away case is marked Cancelled/Merged.
• All activities (emails, notes, tasks) move to the surviving case.
• Maintains audit trail.

Merge is a daily operation in environments where customers report the same issue through multiple channels.

Convert. Cases can convert to other entity types:

• Lead — if the customer is asking about a product, not reporting a problem.
• Opportunity — same.
• Knowledge article — if the resolution is broadly useful, convert to KB content.
• Recurring case template — for repeated issue patterns.

The convert path keeps the case data flowing where it's most useful.

SLA association. Each case can have SLAs applied:

• First response by — time to first agent reply.
• Resolve by — time to close.
• KPIs paused during specific status reasons (waiting on customer doesn't tick).

SLA configuration is per-case-type or per-customer-tier. SLA breaches drive escalations and alerts.

Routing. When a case is created, routing rules determine the queue:

• Origin-based — chat cases go to chat queue.
• Subject-based — billing issues go to billing queue.
• Customer-based — VIP customers go to dedicated queue.
• Skill-based — language, product expertise required.

The unified routing capability layers ML on top — predicts ideal agent based on past resolution data.

Knowledge integration. Cases tied to knowledge articles:

• Agent searches KB while working a case.
• Article linked to case; usage tracked.
• Resolution flag if KB resolved it.

KB usage metrics flow back to content strategy — which articles are working, which gaps exist.

Email-to-case. Inbound email creates or updates cases:

• Mailbox configured as a queue.
• Email processed by server-side sync.
• Subject matching appends to existing case (if reference key present); otherwise creates new.

Reference keys (a Dynamics-generated ID in email subject) tie subsequent replies to the same case. Configure carefully; mismatched keys split conversations into multiple cases.

Resolution. Closing a case:

1. Click Resolve.
2. Select resolution type (Problem Solved, Info Provided).
3. Enter resolution narrative.
4. Enter time spent (billable hours, if relevant).
5. Confirm SLA status.
6. Case status → Resolved.

The resolution narrative feeds knowledge content — well-written resolutions become the seed of KB articles.

Case forms in Workspace. Customer Service Workspace renders cases optimised for multi-session:

• Compact form layout.
• Productivity pane on the side.
• Smart assist suggestions surface inline.

Common pitfalls.

• Subject taxonomy unmanaged. Agents pick subjects ad-hoc; reporting unreliable.
• No SLA discipline. SLA enabled but breaches not actioned; metric pollution.
• Cases reopened without policy. "Resolved" cases reopen routinely; resolution rate inflated.
• Email-to-case duplicates. Misconfigured reference keys split conversations.
• Status reasons proliferating. Every supervisor adds a new reason; reporting becomes incomprehensible.

Operational rhythm. Daily queue review by supervisors; weekly trend analysis by service managers; monthly subject and SLA review by leadership. The case data is rich; using it for continuous improvement is the discipline that distinguishes mature service operations.

Strategic positioning. Case management is the operating system of customer service. Get the fundamentals right — taxonomy, routing, SLA, resolution discipline — before layering on AI features, omnichannel, and analytics. Without a clean case foundation, advanced features amplify rather than fix operational chaos.