Skip to main content

​
Routing rules — auto-assign inbound conversations

Routing rules decide who a new inbound conversation lands with. Each rule sets match conditions — channel, language, keyword, tag, country, contact segment, sentiment, prior agent history — and one action: assign to a user, a team, a round-robin pool, a skill-matched agent, tag the conversation, set its priority, or hand it to an AI agent. Rules are evaluated in priority order (lowest number first) and the first enabled rule whose conditions all match wins — conditions on a rule AND-combine, and a rule with no conditions matches every conversation. Set names and priorities deliberately: priority 1 is checked before priority 10. Every control here is tenant-owned: rules live in your workspace’s settings, take effect on the next inbound conversation, and govern inbound assignment only. They never change how outbound messages or calls are placed. You need an owner or admin role to create, edit, or test rules.

​
Create a rule

  1. Open Inbox → Settings → Routing.
  2. Click Create routing rule.
  3. Name the rule for the intent, e.g. “Spanish WhatsApp → ES team”, and optionally set a priority number (leave it blank to take the next free slot).
  4. Pick the action and its target — the assign-to-user and round-robin actions use searchable roster pickers, so you choose teammates by name rather than pasting ids.
  5. Set the conditions. Leave a facet blank to match every conversation on it.
  6. Run the dry-run (below), then save.
Toggle a rule off with the switch in the list instead of deleting it — the rule stops matching but stays editable.

​
Dry-run before go-live

The rule form carries a dry-run panel. Choose a sample channel, type a sample message body (and optionally a sentiment to preview), then Run dry-run. The result shows whether the rule matched, the language the built-in detector read from the sample, and the action that would fire. Base the sample on a recent real conversation — the detector and matchers run the same evaluation the live engine uses, but nothing is saved or assigned. Save the rule only once the dry-run shows the outcome you intend, and re-run it after every edit.

​
Condition reference

Tags are the dependency to watch: routing on a tag only works once that tag exists and is actually applied to conversations. Define the workspace vocabulary in Inbox tags first, then reference those tags in rules. Typing a tag name the workspace never defined makes the rule match nothing.

​
How routing composes with queues and presence

A rule’s assign action can target a single agent, a team, a round-robin pool, or the agent whose skills best match the rule’s required skills — and digital queues can hand a conversation back to this same rules engine as their overflow action, so a queue that cannot place an item defers here instead of dropping it. Rules and queues compose: attribute routing refines which queue, routing rules decide who answers it. Assignment only considers available agents. An agent who is offline or otherwise unavailable is skipped, exactly as a manual assign respects the presence states in Agent presence lifecycle. If a rule assigns to one specific person, make sure someone is usually available — a round-robin pool or skill-based match survives one person’s absence.

​
API parity

Everything the console does goes through public endpoints under /api/v1/inbox/routing-rules — list, create, update, delete, and the dry-run evaluation the console’s test panel calls. Field-level reference lives in the Inbox API reference; see Omnichannel queue routing for the same evaluator described end-to-end over the API.

​
Troubleshooting

A rule never fires. Check the facets in order: the tag condition fails silently when the tag does not exist or is never applied — create it under Inbox → Settings → Tags and confirm a recent conversation actually carries it. If the rule is tag-clean, re-run the dry-run with a sample that reproduces a real conversation; the no-match result tells you which facet (channel, detected language, keyword, sentiment) rejected it. Sentiment conditions additionally require the conversation to have been scored — a not-yet-analyzed conversation never matches. The rule fires but no agent gets assigned. The matched action found no available target: the specific user is offline or at capacity, the round-robin pool is empty of available members, or the skill-based match has no skilled available agent (skill assignment falls back to round-robin across the org’s users only when nobody overlaps). Check presence for the named targets in the team’s view, widen the pool, or switch the action to skill-based with a broader skill set. The wrong rule wins. First match in priority order takes the conversation — a broad low-numbered rule (for example one with no conditions) shadows every specific rule below it. Reorder by editing priority numbers, and narrow catch-all rules with at least one condition.

​
See also

  • Omnichannel queue routing — attribute and affinity policies that shape which queue an item enters; the routing rules here decide who answers it once it is in the inbox.
  • Inbox settings map — the console this page covers, in context with the eleven others.
  • Agent presence lifecycle — the availability states assignment honors.
  • Inbox tags — the vocabulary tag conditions and Add a tag actions draw from.