Skip to main content
Routing fails quietly. A ticket that should have landed in your review queue sits untouched, with nothing in the interface to say a rule was considered and passed over. Only one rule runs per event. Start on Settings > Routing > Rules; the answer is usually visible on that page before you open anything.

​
Read the rules list the way Rulebase reads it

Conditions prints the whole trigger as a sentence: the event name, then the conditions in brackets joined with and, or (all conversations) when the rule has none. Actions prints what will happen, or - when the rule has nothing to do. Row order on this page is execution order. When an event fires, Rulebase walks the list from the top, skips any rule watching a different event, and stops at the first rule whose conditions all hold. Hovering a row shows a drag handle on the left for reordering, which appears once you have more than one rule. Scan for these before opening your own rule:
  • A rule above yours that would also match this ticket. It runs, yours does not.
  • A rule whose Conditions cell reads Any. It has no trigger set, so it is a candidate for every event.
  • A rule whose Actions cell reads -. It still counts as a match and still stops the rules below.

​
One rule per event, and the top one wins

Matching is not cumulative. If two rules could both handle a ticket, only the higher one does, and the lower one behaves exactly as though it did not exist. Nothing in the interface logs that this happened.
Most workspaces contain a rule nobody created. It reads Any under Conditions with nothing in the brackets, and - under Actions, and it matches any event on a ticket that scored below 80%. It stops the rules under it while appearing to do nothing. If your rules only fail on low-scoring tickets, this is almost certainly why. Drag your own rules above it.
Whatever is absorbing the event, the fix is the same shape: narrow rules at the top, catch-alls at the bottom. A rule with no conditions matches every occurrence of its trigger, so it belongs at the end of the list.

​
The trigger has to be the exact event

A rule only ever sees the one event it names, set in the rule’s When section. Open your rule, read what When is set to, and check it against the list below. Each trigger fires at a different moment. Create rule dialog with the Evaluation approval is requested trigger selected and an Assign to queue action sending the evaluation to a validation queue Submitting a manual evaluation for review raises Evaluation approval is requested. A rule built on Ticket is evaluated will never see it, however well its conditions fit. A rule also cannot fire on an event that never happened. If AI QA never scored the ticket, no evaluated event was raised, and no rule tuning will route it. That is a different problem with a different fix.

​
Conditions must all hold, and some cannot hold at all

Conditions are joined with and, so every one has to be satisfied and each condition you add is another chance for the rule to be skipped. Common silent misses:
  • Blank data fails a condition, including a negative one. A ticket with no channel recorded does not match Channel includes Email, and it does not match Channel does not include Call either. The same holds for Group, Partner, Workspace, and Ticket status: no value on the ticket means no match, in either direction.
  • Failed criteria means scored zero. The condition matches criteria that scored 0 on the evaluation. A criterion that came back partial does not count as failed here, even though the ticket looks like a failure to a reader.
  • Customer sentiment never matches. The field cannot be added from the rule editor under any of the five triggers, and a rule still carrying one from an earlier version does not resolve it against a ticket, so that rule will never fire. Use a QA score condition instead.
When a rule with several conditions is not firing, strip it back to just the trigger. Save it, confirm it fires, then add conditions back one at a time. Much faster than reasoning about which combination excluded the ticket.

​
The rule fired, but nothing appeared to happen

Sometimes the rule matched and the action ran without changing anything. From outside this looks identical to a rule that never fired, but the causes differ, and every one still consumes the event, so the rules below stay skipped. Assignment also picks one person at random. If a rule assigns to a role or a set of members, selecting five people spreads tickets across them one at a time rather than notifying all five, so “my rule didn’t fire” sometimes turns out to be “it fired and picked someone else”. Add a notification action alongside the assignment when everyone needs to see the ticket.

​
There is no on/off switch

A rule’s row menu offers Edit and Delete, and nothing else. Rules cannot be paused, and there is no enabled column. That makes ordering your only non-destructive lever. To take a rule out of play without losing it, drag it to the bottom of the list, or edit it so its conditions no longer match. To take it out permanently, delete it, and check what was sitting below it first, because those rules will start firing on traffic the deleted rule used to absorb.

​
Confirm the fix on the next event

Rules apply going forward only. Fixing the order or loosening a condition does not reach back and route tickets that already went through the trigger, so the ticket in front of you needs assigning by hand. To prove the fix, raise the trigger again on a real ticket and check three things: the ticket lands where you expected, the assignee is someone you intended, and a ticket you meant to exclude was in fact left alone. If the ticket still isn’t routed, go back to the top of the list. A rule above yours matching first remains the most likely answer.