Almanac
Microsoft/d365csDynamics 365

Consultant-focused KB for Microsoft Dynamics 365 Customer Service: implementation notes, gotchas, and configuration decisions beyond the official docs — across case management, queues and routing, knowledge base, SLAs, omnichannel, agent experience, Copilot, analytics, and administration.

feature-skill-based-routing.mdv1 · history
CurrentApplies to EnterpriseUpdated 6 days agoSource Microsoft Learn

What it does

Skill-based routing narrows assignment to people who can actually do the work. Skills with proficiency ratings are held against each user, classification rules attach required skills to the work item, and the assignment stage matches one against the other before it looks at capacity or fairness.

Key facts

  • The moving parts are a rating model (name, min rating value, max rating value), skill types, skills, and per-user skill assignments with a proficiency value. Under the covers these are the Field Service scheduling tables — Bookable Resource Characteristic Type, Bookable Resource Characteristic and Rating Model.
  • Skill types come from the Bookable Resource Characteristic Type option set. Microsoft's own guidance suggests a rating model of 1 to 10 with named levels, but the range is yours to set.
  • Skills are managed in the Skills hub, which creates the bookable resource records for you. The older classic path needs bookable resources set up by hand.
  • The Default skill matching algorithm is a workstream setting with two values: Exact Match and Closest Match.
  • Exact Match requires every attached skill at or above the required proficiency. If nobody qualifies, the item stays in the queue unassigned.
  • Closest Match ranks people by how near they are to the requirement — exactly qualified first, then overqualified, then underqualified — and will assign to someone short of the mark rather than leave the item waiting.
  • Skills only affect routing if skill attachment rules exist in a work classification ruleset. No attachment rules means no required skills means skill routing does nothing, whichever algorithm you picked.
  • Skills can be attached by logical rules or by the intelligent skill finder, an AI Builder custom category classification model. That model needs AI Builder available in the region and only supports AI Builder's languages.
  • Custom assignment rulesets don't inherit the workstream's matching algorithm. You express matching explicitly with conditions like User skills > Exact match > All skills, and can order results by proficiency or skill count.
  • Representatives can be allowed to maintain their own skills, which is a separate configuration and a governance decision as much as a technical one.
  • Skill attachment appends on reroute, so skills accumulate rather than reset.

When to use / skip

Use it where competence genuinely varies and misrouting costs something real: language, regulated product knowledge, tiered technical support, anything where the wrong person means a transfer and a second explanation to the customer. In those settings it pays for itself quickly.

Skip it where the team is broadly interchangeable. Skills add a permanent data maintenance obligation — every joiner, leaver and role change has to be reflected, and nobody enjoys owning that. A support desk of fifteen people who all handle everything gains nothing and inherits a chore.

The honest middle ground is a small number of high-value skills. Two or three languages and a handful of product families will cover most of the routing benefit. Modelling a 40-skill competency matrix because HR already has one is a trap: HR's matrix is for appraisals, and it will not stay in step with routing.

If the client wants the benefit without the maintenance, queue-per-skill with straightforward route-to-queue rules is a defensible alternative, at the cost of a fatter queue list.

Configuration decisions

  • The rating model range and what each level means in words. Pick one model and reuse it — multiple scales across skill types makes proficiency comparisons meaningless to everyone reading them.
  • Exact Match or Closest Match per workstream. Exact protects quality and risks work sitting unassigned; Closest keeps work moving and risks the wrong person. Say which risk the client prefers, in writing.
  • Which skills are modelled at all, and the skill type taxonomy underneath them.
  • Whether skills are attached by logical rules, intelligent skill finder, or both, and what happens when neither fires.
  • Who maintains skill assignments: administrators centrally, team leaders, or the representatives themselves.
  • Whether custom assignment rulesets are needed to order by proficiency, or whether the out-of-the-box methods suffice.

Gotchas

  • Switching a workstream from Closest to Exact Match on a live system can strand work instantly. Nothing errors — items simply stop being assigned. Check the skill coverage of every queue before flipping it.
  • Proficiency is compared against the rating model, so a skill created against a different model than the rule expects will not behave sensibly. Standardise the model early; retrofitting is painful.
  • Users need to be bookable resources with skills attached. A licensed, queue-member user with no bookable resource record is invisible to skill matching and receives nothing, silently.
  • Bulk skill loading above roughly 500 change requests per 15 minutes produces inconsistent results — skills that appear to save and don't take effect. Batch your data loads and verify afterwards.
  • Skills accumulating on reroute progressively narrow the eligible pool. A twice-rerouted case can require a combination nobody has.
  • Letting representatives edit their own skills is fine until it isn't. Without a review cycle, skill data drifts optimistic and Exact Match starts producing wrong assignments rather than no assignments.

Consultant notes

  • Demo the failure case as well as the success case. Show what Exact Match does when nobody qualifies — clients need to see that before they choose it, not after.
  • Get the skill list agreed by the people who run the rota, not by HR. The rota owner knows who can actually take a French case on a Tuesday.
  • Tie skill maintenance into the joiner-mover-leaver process during design and name the owner in the handover. This is the single most common reason skill routing degrades in year two.
  • Before go-live, run a coverage check: for every skill combination your classification rules can produce, confirm at least two active users match. One is not enough — they take holidays.
  • Push back on intelligent skill finder as a phase-one commitment unless the client already has clean, high-volume, well-labelled case data.

Worth another look if the client restructures teams, or if intelligent skill finder's language coverage expands.

Was this accurate?