Work classification rulesets

What it does

Classification is the first stage of unified routing. Rulesets on a workstream read the incoming work item and stamp extra attributes onto it — skills, priority, severity, capacity profiles, custom values — so that the later route-to-queue and assignment stages have something useful to work with.

Key facts

Three ruleset kinds are available: logical rules (a decision list of if/then conditions), machine learning rules using an AI Builder text classification model, and a sentiment prediction ruleset. Check the current release wave before promising the ML and sentiment options as GA.
Quotas: 10 rulesets per workstream, 100 rule items per ruleset, and up to 5 output attributes per rule item. These are organisation-level limits and not adjustable.
Rulesets execute in the order they're listed on the workstream, and rule items execute in order within a ruleset. Attributes set by one ruleset are visible to the next, so ordering is functional, not cosmetic.
Classification runs before the route-to-queue ruleset. Anything you want to condition a queue decision on has to be stamped here first.
Conditions can reach up to two levels of related records and attributes. Deeper than that needs the value denormalised onto the routed record.
Skill attachment rules append skills rather than replace them. Rerouting a case runs classification again, so skills accumulate across passes.
Capacity profile rules attach additional profiles on top of the workstream default. Assignment then requires the person to have headroom in all attached profiles.
Classification is optional. A workstream with no classification rulesets routes fine — it just has nothing beyond the record's own fields to work with.
Microsoft ships template rulesets you can start from, and rule items can be copied, reordered and searched within the ruleset.
Rules that only compare static values are cheap; best practice guidance is to prefer them over ML where a plain field check will do, because they add less assignment latency.

When to use / skip

Use classification the moment routing depends on anything other than the record's own top-level fields, or the moment you want skills involved. Skill-based routing without skill attachment rules does nothing at all — the requirement side of the match is empty — so if skills are in scope, classification is mandatory rather than optional.

Skip the machine learning rulesets on most projects. They need an AI Builder model, region availability, training data the client usually doesn't have in usable shape, and a retraining owner nobody has budgeted for. A dozen logical rules over product, language and customer tier will out-perform an undertrained model and can be explained to an auditor. Revisit ML when the client has real volume, stable taxonomy and someone whose job includes model quality.

Sentiment-driven classification is a nice demo and rarely a good first-release commitment on a records-focused Customer Service build.

Configuration decisions

Which attributes classification is allowed to set: skills only, or priority and severity as well. Letting routing overwrite case priority conflicts with whatever the case management design says about priority — settle that argument before building.
How many rulesets to use, and what each one is for. One ruleset per concern (skills, capacity, priority) reads far better than one giant list, and you have ten to spend.
Whether skills come from logical rules, an ML model, or both, and what the fallback is when neither produces a skill.
Where the values come from: a field on the case, a field on the related account or product (remember the two-level limit), or a denormalised field maintained by a flow.
Whether reroute behaviour is acceptable given that skills append. If not, plan a step that clears skills before rerouting.
Which capacity profiles get attached conditionally versus set as the workstream default.

Gotchas

The 100-rule-item ceiling per ruleset sounds generous until someone models a rule per product code. Model against a category field with a lookup table instead, or you'll hit it and have to redesign mid-build.
Because rulesets read each other's output, reordering rulesets after go-live can silently change routing outcomes for records that previously matched nothing. Treat ruleset order as a controlled change.
Skills appended on reroute make the match narrower each time, so a case that bounces twice can end up matching nobody and sitting in the queue. This looks like a capacity problem and isn't.
Conditions on related records are evaluated against the state at routing time. A case routed before the account tier is populated classifies as untiered, and nothing re-evaluates it later.
ML classification depends on AI Builder being available in the environment's region and on the languages AI Builder supports. Confirm both before designing around it — a client on a region without AI Builder gets nothing and no useful error at design time.
Rule changes take up to 15 minutes to propagate. A tester who saves a rule and immediately creates a case will report it as broken.

Consultant notes

Build the classification design as a table in the design document — condition, output attribute, value — and get it signed off. It is the part of routing the business genuinely understands and has opinions about.
Demo with two contrasting cases side by side, showing the different skills and priority each picked up. Abstract explanation of classification never lands; two cases does.
Push back hard on requests to classify on free-text description with logical rules. It works in the demo and fails on real data.
Before go-live, count rule items per ruleset and record the number in the handover. The client's own admin needs to know how close to 100 they are.
Check that every skill your rules can attach actually exists on at least one active user. Rules that attach an orphan skill produce unassignable work items.

Worth another look when the ML and sentiment rulesets change status in a release wave, or if the client's product taxonomy is restructured.