Case per issue or case per customer contact

What it does

Before anything else in a Customer Service implementation, someone has to decide what a case represents. One case per underlying issue, worked until resolved regardless of how many times the customer gets in touch. Or one case per interaction, opened and closed each time. Everything downstream — SLAs, reporting, routing, agent behaviour, the shape of the parent-child hierarchy — falls out of that choice, and changing it later means re-baselining every number the client has ever reported.

Key facts

Dynamics does not enforce either model. The case table supports both; what differs is the configuration and the working practice around it.
Parent and child cases are the native mechanism for the issue model. A parent holds the issue, children hold the work streams or the individual customer reports of the same problem.
Child cases inherit attributes from the parent. Case Title and Customer are always inherited; you choose which additional attributes join them.
Closure behaviour is one of two settings: close all child cases when the parent closes, or block parent closure until every child is closed. You pick one for the whole organisation, not per case type.
You can cap the maximum number of child cases per parent. Microsoft's own guidance is to keep the number low for performance reasons during resolution and merge, so treat a high cap as a warning sign about the model.
Merging cases exists for the duplicate-contact problem, and merging moves activities onto the surviving case. It is not a substitute for a deliberate granularity decision.
SLAs attach to the case. In a case-per-contact model, each contact restarts the clock, which flatters the numbers considerably.

When to use / skip

Default to case per issue. That is the recommendation and it holds for the large majority of service organisations. It matches how customers think — "my problem", not "my third phone call" — it makes the case history readable, it produces resolution times that mean something, and it stops the same problem being worked three times in parallel by three agents who cannot see each other.

Case per contact is right in a narrower set of situations, and they are real ones. Contact centres where the interaction genuinely is the unit of work — general enquiries, information requests, signposting, most of local government's front door — have no persistent issue to hang a case on. Forcing a parent-child model onto them creates empty parents and agents opening cases they will close in ninety seconds. Organisations with per-interaction billing or per-interaction regulatory logging also need the contact to be the record.

The trap is the hybrid, and it is where most projects end up by accident rather than design. Some teams work issues, some work interactions, everyone uses the same case table, and the reporting is meaningless within a year. If the client genuinely has both patterns, model them explicitly — different case types, different forms, different SLA sets, and a reporting layer that never sums them together. Do not let it happen by drift.

The one situation where I would move away from case-per-issue against instinct is a client migrating from a legacy system that recorded interactions and has five years of history they intend to keep. Reshaping historical interaction records into issues is a data migration project of its own, and it is rarely worth it. Keep the legacy shape for history, adopt case-per-issue for new work, and be explicit in reporting about the break.

Configuration decisions

What a case represents, stated in one sentence in the design document and agreed by the service leadership, not by the project team alone.
Whether parent-child is used at all, and if so for what — one issue with multiple work streams, or one incident affecting many customers. Those are different patterns and need different guidance for agents.
Which attributes children inherit beyond Case Title and Customer. Inheriting priority and case type is usually right; inheriting owner usually is not.
Which closure preference applies: cascade closure to children, or block the parent until children are closed. Cascade suits the mass-incident pattern; blocking suits the multi-workstream pattern.
The child case cap, set low enough that resolution and merge stay quick. If the real requirement needs hundreds of children, the model is probably wrong.
Whether SLAs attach at parent, child or both, and how pausing works when a child is waiting on the customer.

Gotchas

Closure preference is a single organisation-wide setting. Teams that want opposite behaviours cannot both have it, and discovering that in UAT is a design rework, not a configuration change.
Cascade closure closes children silently. Agents working a child case find it resolved under them with no notification, which reads as a system fault the first few times.
High child counts hurt performance on resolution and merge. The documentation says so plainly, and the projects that ignore it find out during volume testing.
In a case-per-contact model, first-contact resolution and average resolution time look excellent and mean nothing. Clients present those numbers to their board. Have the conversation about what they measure before, not after.
Migrating history from a system with a different granularity produces two incompatible populations in one table. Flag the migration date in the data and in every report definition.

Consultant notes

Ask the client to describe, out loud, what happens when the same customer calls three times about the same problem. Their answer is the granularity decision, and it usually contradicts what the requirements document says.
Write the definition of a case on one slide and get it agreed at steering. It is the single most useful page in the design document and the one people return to for years.
Demo the parent-child behaviour with cascade closure switched on. Agents react strongly and you want that reaction before the setting is locked in.
Check the child case cap and the closure preference in the production environment before go-live. They are easy to configure in a sandbox and easy to forget in the deployment checklist.
If the client asks to change the model six months in, cost the reporting re-baseline as well as the configuration. The configuration is the cheap part.

Worth another look if Microsoft ever makes closure preferences configurable per case type — that single change would reopen the hybrid conversation.