East-office laptop
The site-specific laptop rule wins over the broader hardware rule. The saved ticket records which rule made the assignment.
Assign incoming issues by category, location, and equipment context. Use ordered rules, keep the matched rule visible, and send unmatched or unstaffed cases to triage.
Explore with sample data. Adapt fields, views, and workflows for your team.
| Order | Match | Destination | Result |
|---|---|---|---|
| 10 | Meeting room + any location | Workplace support | If the destination has no technician, keep the ticket in triage. |
| 20 | Hardware + East office + laptop | Service desk | A specific site and device rule is evaluated first. |
| 30 | Hardware + any location + any asset | Service desk | A broader rule catches devices without a more specific match. |
| No match | Other combinations | Triage | An explicit fallback is better than an invisible unassigned ticket. |
The site-specific laptop rule wins over the broader hardware rule. The saved ticket records which rule made the assignment.
The general hardware rule provides a destination when the narrower laptop rule does not apply.
The category matches, but the missing assignee sends the case to triage. A matching category is not sufficient if nobody will receive the work.
No rule matches the new combination. The ticket remains visible with an unmatched result, ready for a support owner to assign.
Give each active rule a distinct order. Put the most specific exceptions before general rules and inspect overlapping combinations before enabling a change.
Record the new team, technician, and reason in a ticket update. Changing a routing rule should affect future intake, not silently overwrite a person’s deliberate handoff.
A growing triage queue may mean a new service category, incomplete input, or a missing handler. Fix the cause instead of adding an excessively broad rule that hides it.
This is deterministic rule-based assignment. It does not claim AI classification, skill inference, workload balancing, or round-robin distribution. Those require their own routing model and acceptance tests.
Review unmatched cases regularly. A recurring category may need a new rule, while a one-off exception may only need manual assignment. Before changing a rule, confirm the receiving technician is available and accepts that work. Try one matching case and one case that should fall through to the next rule. New rules apply to new submissions; they should not silently move tickets that somebody is already handling.
The matching rule with the lowest order wins. Keep orders unique and test both specific and general examples so a broad rule does not swallow a deliberate exception.
Yes, when no rule matches or the destination lacks a technician. The example makes that state explicit in the triage queue rather than pretending the ticket was successfully assigned.
The initial routing process is for new tickets. Use a recorded manual reassignment when an existing case needs another owner; do not assume a rule edit changes the current queue.
The example calculates priority from impact and urgency and retains it on the ticket. Its routing rules use category, location, and asset class; adding priority-based destinations is a separate rule change to configure and test.
No. The rules are explicit and inspectable. Use this approach when the organization can describe its assignment policy; evaluate a specialist option when classification or workload optimization is the main requirement.
Test specific, general, unmatched, and missing-handler cases before applying the assignment policy to live employee tickets.