Parent and child cases

What it does

A case can be linked to a parent case, giving you one master record for an incident and a child case per affected customer or per work stream. Admin settings control which columns children copy from the parent, how many children a parent may have, and what closing the parent does to the children.

Key facts

Configured in the Copilot Service admin center under Case settings > Parent child case settings. Needs Customer Service Manager, System Administrator or System Customizer.
The hierarchy is exactly two levels. A child case can't have children of its own, and a parent case can't be made the child of another case.
Attribute inheritance is a defined list. Case Title and Customer are mandatory and always inherited; you pick any additional columns from an available/selected picker.
Inheritance happens at child creation. It is not a live link — later edits to the parent don't push down.
Closure preference is a single choice between two behaviours: close all child cases when the parent is closed, or don't allow the parent to close until all children are closed. Leaving it unset means parent and child close independently.
You set a maximum number of child cases per parent. Microsoft's own guidance is to keep this number small because resolving or merging cases with many children degrades performance.
Children are created from the case form via Create Child Case, or from the Case Relationships tab, and an existing case can be attached as a child with Add Existing Case.
Child cases don't appear in the Regarding lookup for activities by default. That's customisable, but it catches people out when they try to file an email against a child.
Resolving a parent that has active children still requires open activities to be dealt with first — the closure preference doesn't bypass activity validation.
Merging interacts with the hierarchy: a merged case's children become children of the surviving case, and you can only merge a child into another child under the same parent.

When to use / skip

Use parent/child where one underlying fault produces many customer contacts — an outage, a product recall, a failed batch job. The parent holds the investigation and the comms, the children hold the individual customer relationships, SLAs and closure notes. It's also reasonable for a single complex case split into work streams handled by different teams.

Skip it where the client just wants to group related cases for reporting. A lookup, a category or a tag does that without dragging in inheritance and cascade rules. Also skip it when the volume model is wrong: hundreds of children under one parent is exactly the shape Microsoft warns about, and a major-incident record with linked cases modelled another way will behave better.

Configuration decisions

Which columns children inherit beyond title and customer. Priority, subject, case type and origin are the usual candidates; be careful with owner and queue, since inheritance can undercut routing.
Which closure preference — cascade close, block until children are closed, or neither. This is the decision the business will feel every day.
The child case limit, and what the business does when it's hit during a real incident.
Whether children get their own SLA and entitlement treatment or ride on the parent's. Decide with whoever owns that design; the child inherits only what you configured, not the parent's SLA state.
Whether agents may attach existing cases as children, or only create new ones. Attaching existing cases is how hierarchies get messy.
Whether child cases should be selectable in the activity Regarding lookup, which needs a customisation.

Gotchas

Inheritance is a one-off copy. Clients regularly assume changing the parent's priority updates twenty children, and it doesn't.
The two-level limit is absolute. Any design with grandchildren needs rethinking, and it's better to find that out in the workshop than in build.
Cascade close resolves children without an agent ever opening them, so whatever resolution notes and close data the business wanted on each child simply won't be there.
The block-until-children-closed option can strand a parent when a child is stuck with an inactive owner or an unclosed activity. Agents can't force it.
Saving inheritance settings without both mandatory attributes selected produces a warning — Case Title and Customer must be in the selected list.
Big hierarchies slow down resolve and merge operations. The performance warning in the docs is real, not boilerplate.

Consultant notes

Model a real incident with the client on paper first: how many children, who closes them, what the customer sees. Ten minutes there saves a rebuild.
Demo cascade close and let the business watch twenty cases resolve with no notes. They usually change their mind about which closure preference they want.
Tell the client the hierarchy is two levels deep before they design a three-tier taxonomy around it.
Check how parent/child interacts with the client's SLA and reporting definitions — "cases resolved" counting cascade-closed children flatters the numbers considerably.
Before go-live, test resolve on a parent with open activities, a stuck child, and an inactive owner. Those three cover most of the live support calls you'll get in week one.

Worth another look if the client's incident volumes grow, or if Microsoft ever lifts the two-level restriction.