## TL;DR
Order rules from most specific to most general, route on two or more conditions (category + location, or CI + service), and test every rule with real ticket examples before activating. Most routing failures are rule-order problems or single-condition rules that overlap.

## The error
```text
(Tickets landing in the wrong group.)
```

## Steps
1. List the groups and what each owns, in plain language. Expected: ownership map. If two groups both claim "network issues", fix the ownership before writing rules.
2. Write rules most-specific first: e.g. category=network AND location=Tokyo before category=network. Expected: ordered. ServiceNow evaluates top-down and stops at the first match.
3. Use at least two conditions per rule where possible. Expected: specific rules. Single-condition rules (just "category") overlap and misroute.
4. Add a catch-all rule at the bottom routing to the service desk. Expected: present. Every ticket must land somewhere; unrouted tickets rot.
5. Test with 20 real historical tickets: run each through the rules mentally or in a sub-prod instance. Expected: 90 percent+ correct. Fix the misses, then activate.

## When to use
- New routing setup
- Misrouted ticket complaints

## When not to use
- Category auto-fill (different feature)
- Priority calculation

## Compatibility
- ServiceNow assignment rules engine

## Variants
### Round-robin within a group
Use workload-based assignment rules if individuals must be picked; groups are usually enough.
### Skills-based routing
Advanced; start with group routing and add skills only where needed.

## Why it happens
Routing is a classification problem solved by ordered rules. The two classic bugs are overlapping rules (order fixes) and under-specified rules (more conditions fix).

## Edge cases
- Document each rule's intent; future admins will reorder blindly otherwise.
- Re-test after org changes; new teams break old rules.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_sVEiqt2BUqZWlIYDqXLb3g