Route-to-queue rules

What it does

The second stage of unified routing. After classification has stamped its attributes on a work item, a single ordered ruleset on the workstream decides which queue the item lands in. Each rule is "if these conditions hold, route to this queue", and anything that matches nothing goes to the workstream's fallback queue.

Key facts

A workstream has exactly one route-to-queue ruleset. You cannot chain several; everything happens in one decision list.
The quota is 200 route-to-queue rules per workstream, at organisation level and not adjustable.
Conditions reach up to two levels of related records and attributes. For record workstreams the top-level condition on the routed record type is pre-populated for you.
Guidance is to keep a rule under about 15 link-entity elements. Beyond that you risk evaluation timeouts, which surface as work items that don't route rather than as an error.
Two evaluation policies: Hit-all (the default) evaluates every rule plus queue overflow state, assigns to the first matching rule's queue if no queue is overflowing, and falls to the first available queue if they all are. Hit-first stops at the first match regardless of overflow.
Percentage-based allocation lets one rule spread work across up to 5 queues, with the percentages summing to 100. Overflow rules still apply on top.
Each rule can carry its own overflow behaviour via Handle rule-specific overflows, overriding the queue's own settings for that traffic.
No rules defined, or no rule matched, means the fallback queue. There is no "leave it unrouted" outcome.
Rules are reordered with the arrows in the Order column, and order is the whole logic — there is no priority field or scoring.
Route-to-queue runs after all classification rulesets, so any attribute classification set is available as a condition here.

When to use / skip

Every record workstream needs at least one route-to-queue rule unless you're genuinely happy with everything going to the fallback queue, which is a legitimate design for a single-team support desk and nothing to be embarrassed about.

The judgement call is how much logic to put here versus in classification. My default: classification derives the meaningful attributes (tier, language, product family, skills), and route-to-queue does a small number of straightforward matches on those. If your route-to-queue list is 60 rules deep with nested related-record conditions, the classification stage isn't pulling its weight and the ruleset will be unmaintainable within two releases.

Percentage allocation is worth reaching for in exactly one scenario — deliberately splitting volume across parallel teams, typically an outsourced partner and an internal team. Don't use it to approximate load balancing; that's the assignment method's job.

Hit-first versus Hit-all deserves an actual decision rather than leaving the default. Hit-all is more forgiving under load; Hit-first is more predictable and much easier to explain when the client asks why a case went where it did.

Configuration decisions

Rule order, which is the entire logic of the ruleset. Write it out most-specific-first and confirm nobody can insert a broad rule at the top later without review.
Hit-all or Hit-first, per workstream. Decide it against how the client wants overflow to interact with routing choice.
Which conditions live here versus being pre-computed in classification, given the two-level relationship limit.
Whether any rule needs percentage allocation across queues, and how the split is reviewed when volumes change.
The fallback queue, and whether it is a real supervised queue with members or a dumping ground.
Which rules need rule-specific overflow behaviour rather than inheriting the target queue's settings.

Gotchas

Rules whose conditions can both be true will resolve by order, not by specificity. A rule matching "language = English" placed above "language = English AND tier = Platinum" makes the second rule dead, and nothing flags it.
With Hit-all, a matching rule whose queue is overflowing can be skipped in favour of a later rule's queue. Clients reading the ruleset top-down will not expect that and will report it as a bug.
Deep related-record conditions are the usual cause of "some cases route and some don't". The failure mode is a timeout on evaluation, not a visible error, so it looks intermittent.
Deactivating a queue that a rule points at doesn't invalidate the rule. Work goes nowhere useful and the ruleset still looks healthy.
Percentage allocation is evaluated per item, so small daily volumes will not look like the configured split. A 50/50 rule over 12 cases a day will produce complaints in week one.
Attributes set by classification are only usable here if the classification ruleset actually ran and matched. Test the unmatched path explicitly, not just the happy path.

Consultant notes

Print the ruleset in order and walk it with the business, one rule at a time. Route-to-queue is the artefact clients most often discover they misunderstood, and it's cheap to fix before go-live.
Demo the fallback path deliberately. Show a case that matches nothing, show where it lands, and get the client to name the person who watches that queue.
Resist per-customer routing rules. They start as three VIP accounts and become forty rules nobody dares delete. Use a tier field on the account and one rule.
Before go-live, check every rule's target queue is active, private and has members, and note the rule count against the 200 limit in the handover.
If routing looks intermittent in UAT, count link-entity elements in the failing rules before you go anywhere near support.

Worth another look if the client's queue structure is reorganised, or if the ruleset creeps past about forty rules.