Subject tree for case categorisation

What it does

The subject tree is a single hierarchy of subjects used to classify cases. It's one shared tree per environment, maintained centrally, and surfaced on the case form as the Subject lookup.

Key facts

Managed in the Copilot Service admin center under Case settings > Subjects. Requires Customer Service Manager, System Administrator or System Customizer.
Subjects are arranged parent-to-child by setting the Parent subject on each node, which also means a subject can be moved later by editing that field.
Microsoft's guidance is to keep the whole tree under about 1,000 subjects including children. Beyond that you should expect performance problems, not a hard block.
There's a toggle to restrict selection to leaf nodes — users can only pick subjects that have no children. Useful for forcing specific categorisation rather than agents stopping at the top level.
Individual subjects can be hidden from service representatives without being deleted, which is how you retire a category without breaking existing records.
The subject management page has its own search, and that search control can't be turned off through configuration.
Deletion is available from the page, but the docs don't spell out cascade behaviour on records already using the subject — treat delete as a last resort and prefer hiding.
The same tree is used elsewhere in the platform, notably knowledge articles, so it isn't a case-only taxonomy even though it's managed from Case settings.
Subject is a lookup to a table, not a choice column. That matters for reporting, for integration mapping, and for anyone expecting an option set.

When to use / skip

Use it when the client needs a hierarchical, maintainable classification for cases that business users can extend without a solution deployment — product families, service lines, fault categories. It's the right tool when the taxonomy is deep and changes over time.

Skip it if the classification is flat and short. A choice column on the case is simpler for agents, easier to report on, and doesn't drag along a shared hierarchy. Also skip it if the classification is genuinely case-specific and the client also wants a completely different taxonomy for knowledge — one tree serving two purposes is how subject trees grow to four thousand nodes and nobody can find anything.

Configuration decisions

How deep the tree goes. Two or three levels is usable; four is where agents start guessing.
Whether agents may pick any node or only leaf nodes. Leaf-only gives clean reporting and slower data entry.
Whether the same tree serves cases and knowledge articles, or whether you accept branches that are only meaningful to one of them.
Who owns the tree after go-live — a service manager with the right role, or a change request each time. This decision is what determines whether the taxonomy stays useful.
Whether Subject is mandatory on the case form, and if so, at creation or at resolution. Asking for it at creation from an inbound email means automation has to set it.
What automation sets the subject for cases created by rules, since a subject lookup won't populate itself from an email.

Gotchas

The tree is shared. A branch added for knowledge shows up in the agent's case subject picker unless it's hidden, and vice versa.
Hiding a subject removes it from selection but doesn't clear it from existing cases, so reports keep showing categories the business thinks it has retired.
Past roughly a thousand nodes performance degrades, and it degrades in the picker where agents feel it most.
Reparenting a subject changes what historical reporting rolls up to, silently. A restructure can make last quarter's numbers move.
Because Subject is a lookup, integrations and import routines have to resolve names to GUIDs. Duplicate subject names in different branches make that ambiguous, and nothing stops you creating them.
Nobody governs it by default. Six months in, agents have raised requests for thirty new subjects and the tree has become an unusable list.

Consultant notes

Ask to see the client's existing categorisation — a spreadsheet, a legacy tool's dropdown — before designing anything. They always have one, and it's usually too long.
Push back on categorising for the sake of it. If nobody can name the report that uses the subject, don't make it mandatory.
Demo the leaf-only toggle. Clients usually want it once they see agents stopping at the top-level node.
Agree an owner and a review cadence for the tree at design time, and write it into the support handover.
Before go-live, check that automation creating cases sets a subject, or accept that a large share of cases will be uncategorised regardless of how good the tree is.

Worth revisiting once real case volumes show which branches actually get used, or if the tree grows past a few hundred nodes.