Merging duplicate cases

What it does

Merge takes a set of cases and folds them into one surviving case. The cases being merged are closed off with a system status of Merged, and their activities, emails and attachments are reassociated with the case you merged into.

Key facts

Up to 10 cases can be merged in one operation.
The cases that get merged away end up in state Canceled with status reason Merged. They are not deleted, and they still count in any view or report that doesn't filter on status.
Activities, emails and attachments move across to the surviving case. That's the point of the feature — the conversation history ends up in one place.
If a case you merge already has child cases, those children are reparented onto the surviving case.
A child case can only be merged into another child case when both share the same parent.
Merged cases are visible afterwards in the Merged Cases section on the Case Relationships tab of the surviving case, so the trail is preserved.
The case picker in the Merge Cases dialog uses the Merge Incident view, and that view cannot be customised. You get the columns and filters Microsoft ships.
Merged is also available manually: cancelling a case lets the agent choose Canceled or Merged as the status, which is how cases get flagged as merged without the merge command ever running.
Microsoft documents no undo. Reversing a merge means reactivating the merged case and moving records back by hand or by flow.
Merging cases with large child hierarchies is one of the operations Microsoft explicitly calls out as a performance concern, which is why the child case limit exists.

When to use / skip

Merge is for genuine duplicates: the customer emailed and then rang, or three agents each raised a case for the same fault. Use it, train agents on it, and make it part of the triage routine — duplicate cases wreck SLA reporting and mean two people work the same problem.

Don't use it as a general "link these cases" tool. Merge is destructive to the source cases' lifecycle, and if the business actually wants related-but-separate cases, that's parent/child or a lookup. Also think twice before letting merge run across different customers; the surviving case keeps one customer, and the correspondence history of the other customer now sits on a record that isn't theirs, which is a data protection conversation you don't want to have retrospectively.

Configuration decisions

Who can merge. It's a command on the case grid and form, so if you want it restricted, that's a security role and command visibility decision, not a setting.
Whether merge is part of a documented triage step, or something agents do ad hoc when they notice a duplicate.
How duplicates get spotted in the first place — a duplicate detection rule, a view of cases per customer in the last 24 hours, or agent judgement.
What views and dashboards filter out status Merged. Every "open cases" and "cases created" figure needs checking against it.
Whether the business needs a reason recorded for the merge, which means a custom column on the surviving case and a habit rather than a system-enforced field.
Whether the fixed Merge Incident view gives agents enough to identify the right target case, or whether they need a different route to find duplicates first.

Gotchas

The Merge Incident view can't be customised, so if agents can't tell two similar cases apart from the columns shown, your answer is process, not configuration.
Merged cases are cancelled, not resolved. Any report counting resolutions won't see them, and any report counting cancellations will inflate.
SLA behaviour on a merged-away case follows whatever your SLA design does on cancellation — check it, because a duplicate that was breaching can silently disappear from the breach numbers.
There's no supported undo. Agents merging the wrong pair is a real support ticket, and the recovery is manual.
Reparenting means a merge can quietly reshape a hierarchy, and it can push the surviving parent past the configured child case limit.
Timeline noise: the surviving case ends up with every email from every merged case, which is exactly what was asked for and still surprises people when the timeline is 200 entries long.

Consultant notes

Demo merge with two cases that have real email threads on them. Agents care about the timeline outcome, not the dialog.
Tell the client early that merge can't be undone and put the recovery process — reactivate and move records — in the support runbook rather than discovering it live.
Check every out-of-the-box and custom case view for status filtering before go-live; merged cases showing up in open-case queues is the classic post-launch complaint.
Push back on merge across different customers unless the business has a clear rule for it, and raise the data protection angle explicitly with a UK client.
Pair merge training with duplicate detection. Agents who can't find duplicates won't merge them, and the feature just sits there.

Worth revisiting if merge volumes grow or if Microsoft ever makes the merge picker view configurable.