Routing rules: conditions and actions
Routing rules match inbound conversations against conditions and apply actions automatically. Here is what you can match on, what you can do, and how to order them so they actually work.
Routing rules let you change what happens to a conversation the moment it lands. Each rule is one condition plus one action. The first rule whose condition matches wins, and its action is applied. Then evaluation stops.
That last part is the part people miss. Rules are not "all that match, run." They are "first match wins." Order is everything.
Configure rules at Settings → Routing. Each rule has a name, an enable toggle, an order (drag to reorder), one condition, and one action.
What you can match on
Each rule has exactly one condition. The supported conditions are:
- Channel is —
email,chat(the live widget), orslack. - Subject contains — case-insensitive substring match against the email subject.
- From domain is — suffix match against the sender's email domain. Useful for VIP routing.
- Priority is at least —
low,normal,high, orurgent. Matches if the conversation's current priority is at or above the threshold. - First message in thread — fires only on the first inbound message of a conversation.
- Custom field — pick a custom field, an operator (
equals,does not equal,contains), and a value. See Custom fields.
There is no AND-of-multiple-conditions and no OR. If you need conjunctions, model them as separate rules layered in order.
What a rule can do
Each rule has exactly one action. The supported actions are:
- Assign to — a specific teammate, or
round-robinto spread across the team. - Set priority —
low,normal,high, orurgent. Priority is what the SLA layer keys off, see SLA policies. - Add tag — append a tag to the conversation, deduped against existing tags.
That's the full set. There is no "snooze" action, no "send auto-reply" action, and no "set status" action in v1. Auto-replies are configured separately at Auto-replies; status changes are agent-driven.
First match wins
Rules are evaluated top to bottom on every newly-ingested conversation. As soon as one matches, its action fires and evaluation stops.
Specific rules go on top, broad rules on the bottom. A reasonable order:
- Emergency keywords (
subject contains"down" or "outage"). - VIP customers (
from domain isyour enterprise list). - Channel defaults (
channel is slack→ assign to a partner team). - Catch-all (
first message in thread→ assign round-robin).
If the catch-all goes on top, nothing else fires.
Disabling a rule
Each rule has an enable toggle. Disabled rules stay in the list but are skipped during evaluation. Use this to A/B a routing change or pause a seasonal rule without losing it.
When rules apply
Rules run on the first inbound message of a new conversation. Editing a rule does not retroactively re-route conversations already in flight — they keep whatever assignment, priority, and tags they had at the time. To fix a batch of mis-routed conversations, do it manually.
Common patterns
The VIP lane. Condition: from domain is acme.com. Action: set priority urgent. Layer a second rule below it (priority is at least urgent → assign to a senior agent) to direct urgent conversations to a specific person.
The bug-report lane. Condition: subject contains [bug]. Action: add tag bug.
The first-touch tagger. Condition: first message in thread. Action: add tag new-conversation. Useful if you want a tag that distinguishes brand-new threads from later messages on existing ones.
The custom-field router. Condition: custom field plan equals Enterprise. Action: assign to enterprise-team-lead. Custom-field routing is the most powerful pattern once you have customer attributes pulled in from Stripe or HubSpot.
Related
- Routing overview for the bigger picture.
- SLA policies for what happens after priority is set.
- Office hours for the business-hours-only timing toggle.
- Auto-replies for first-touch acknowledgements.
- Custom fields for the custom-field condition.
Was this article helpful?