An outage hits your checkout page and forty customers open forty cases about the same thing. Or the opposite: one impatient customer emails twice, calls once, and now three agents own three copies of the same problem. Both situations clog a service queue in their own way, and Dynamics 365 has a built-in answer for each — parent and child cases for the first, merge for the second. Neither needs any customization, and both live right on the case grid.
Two problems, two tools
It is worth being precise about which tool solves which problem, because teams mix them up constantly. Parent-child is for many customers, one root cause — you keep every case (each customer deserves their own thread and their own resolution email) but you work the fix once, on the parent. Merge is for one customer, duplicate cases — the extra copies should stop existing as separate work items, and everything they carried folds into the surviving case.
Select two or more cases in any case view and the command bar offers both actions side by side.
Parent and child cases
With the related cases selected, click Associate Child Cases. Dynamics asks one question: which of these is the parent?
Pick the case that best represents the root cause and click Set. The others become its children. From that point the parent is the single place where the real work happens; the children stay open, keep their own customers, activities and SLA clocks, and remain individually answerable.
The payoff comes at resolution time. In the Customer Service settings, an administrator decides how closure cascades: you can require all child cases to be resolved before the parent can close, or — the setting most service desks want for outage scenarios — resolve every child automatically when the parent is resolved. The same settings page also lets you pick attributes that children inherit from the parent when they are linked, so things like product or case type stay consistent across the family. Two structural rules to remember: a case can only have one parent, and the hierarchy is one level deep — a child cannot have children of its own.
Merging duplicates
Merge Cases handles the second problem. Select the duplicates, click the command, and pick the case that survives.
Note the warning in the dialog: you can’t undo this action, so read the list before you commit. When you merge, the losing cases are cancelled and everything that made them useful — activities, emails, notes, attachments — is re-parented onto the surviving case. Any child cases of a cancelled case move over too. The cancelled duplicates do not vanish; they stay in the system as cancelled, cross-referenced to the winner, so the audit trail survives. You can merge up to ten cases in one pass.
A few practical rules the dialog will enforce for you: you cannot merge a case into a case that is itself already merged elsewhere, and if the cases belong to different customers Dynamics will warn you — usually a sign you selected the wrong rows.
Which one, when
My rule of thumb for agents is a single question: would each of these cases send its own resolution email? If yes — different customers affected by one incident — use parent and child, work the parent, let the cascade close the family. If no — it is the same conversation split across copies — merge and keep the queue honest. Teams that adopt this discipline see their open-case counts drop to something that finally reflects reality, which makes every downstream number (SLAs, workload dashboards, routing) more truthful too.
Both features are old, stable, and free — the only investment is teaching the team that the two buttons exist.
