Configuring Routing

The workspace Routing settings page is where the rules live. The Group details and Team member pages then show you how those rules play out for a specific team or person, with a few light controls on top — group membership, the active/paused toggle, and the queue order for a team.

This guide walks through the Routing settings page first, then how to read the group and team-member views, with a short tour of how the engine actually picks an assignee in between.

For guidance on designing the groups themselves, see Creating Groups. For response-time targets and breach tracking, see SLA Policies.

Where things live

How routing actually works

Applied uses a pull model, not a push model. A conversation does not get handed to a person the moment it escalates — it gets placed in a queue with a priority stamp, and team members pull from queues as their capacity frees up.

The lifecycle of one escalated conversation:

1. Queue selection. Queues are evaluated first-match-wins in their configured order. The first queue whose conditions match owns the conversation. The Default queue is a pinned, unconditional catchall that matches anything no other queue did.
2. Target group. The matched queue’s Routes to is resolved. For a single-group queue, that’s the only target. For a weighted split, a per-conversation weighted random draw picks one group as the primary. The pick is committed to the conversation and is never re-rolled.
3. Priority stamp. Priority rules are evaluated first-match-wins and the conversation’s priority is set once, at escalation time.
4. Try to assign. The system attempts to pick an eligible member of the target group right away using the assignment strategy. If it finds one, it assigns; if it doesn’t, the conversation waits in the queue.
5. Drain on capacity. Whenever a member’s capacity frees up — when they resolve a conversation, when one is unassigned from them, or when they come back online — the system drains their queues, pulling the highest-priority oldest waiting conversation that targets one of their active groups.

Two consequences of the pull model worth internalising:

• A conversation can sit in a queue with no assignee for some time. That’s the system waiting for capacity, not a bug.
• The order conversations come out of a queue is priority first, then age — not strictly FIFO.

Eligibility

A team member must clear all of these checks to receive an assignment:

• Their invitation has been accepted.
• Their Group membership in the target group is Active (not paused).
• They are not currently on a live phone call (for chat and phone routing).
• Their user status is not Out of Office.
• Their current load on the relevant channel is below the cap from their capacity rule.

If no member of the target group clears all the checks, the queue’s fallback group (if configured) is tried next under the same rules.

Routing settings page

The routing page is split into four tabs.

Strategy

Picks how an escalated conversation is handed to a specific person inside the group the queue points at.

• Manual — no auto-assignment. The conversation lands in the group but no individual is picked. Team members claim it themselves from inbox views.
• Round robin. Cycles through the eligible members of the target group. The cursor is per queue–group pair, so two queues that both route to “Tier 1” rotate independently. Members at capacity, on a call, or out of office are skipped, not waited on.
• Assign to specific member. Always assigns to one chosen person, regardless of group. Useful for single-agent workspaces or for staging.

Below the strategy, Conversation reopening mode controls what happens when a closed conversation is reopened.

• Keep previous assignee. The reopened conversation stays with whoever closed it.
• Reassign using strategy. The full routing pipeline runs again — queue selection, priority, and assignment — so the reopened conversation can end up with a different group, a different priority, and a different agent than it had before.

Queues

Queues are ordered rules that map a conversation’s attributes — topics, intents, channel, contact, labels, and more — to a target group. They are evaluated strictly top-down, first match wins. Drag the grip handle on the left of each row to reorder them.

Each queue has:

• Name. A short label for the rule.
• Conditions. A condition builder over conversation attributes. Combine conditions with AND / OR logic.
• Routes to. Either a single group, a weighted split across multiple groups (the Routes to column shows a 60% / 40% style split detail when more than one group is targeted), or Leave unassigned for a manual-pickup sink. For a weighted split, every conversation that matches this queue runs an independent weighted random draw — over many conversations the realised mix converges on the weights, but two conversations in a row can both go to the same group.
• Fallback group. Tried when nobody in the target group is eligible.
• Stop on match. Controls what happens after this queue matches but fails to assign anyone. When on, the conversation stays in this queue forever waiting for capacity. When off, you allow a graceful fallthrough so other paths can pick it up later. stop_on_match does not change which queue matches first — it only changes whether failure to find an assignee is terminal.
• Active. Inactive queues are skipped entirely during evaluation.

The Default queue is pinned at the bottom and always evaluates last. It is the catchall for conversations that no other queue matched, and it has no conditions. You cannot delete it, but you can change its target group.

You can optionally have the queue create a public saved view in the inbox when you save a new queue, so the team has somewhere to watch that queue’s conversations from.

Priority

Priority rules tag matching conversations with a priority tier. They use the same ordered, first-match-wins evaluation model as queues, with an unconditional default at the bottom.

The five tiers are:

• None — no special priority
• Low
• Medium
• High
• Urgent

Priority is stamped on the conversation once, at the moment it enters the queue. It then drives the order conversations are pulled out of the queue when an agent’s capacity frees up: a higher-priority conversation is pulled before a lower-priority one in the same queue, regardless of arrival order. Older conversations break ties within a tier. Priority also drives the SLA urgency sort in inbox views, so the conversations agents will actually be handed next are also the ones surfaced at the top.

Priority is independent of which group the conversation routes to.

Capacity

Capacity rules cap how many concurrent conversations a member can be assigned on each channel. The list is ordered; for any given member, the first rule whose group the member is an active member of wins. A member who is in no rule’s group falls through to the Default rule.

The channels tracked are:

• Chat
• Phone
• Email
• SMS
• Comments

Each cell holds an integer cap. When a member is at cap on a channel, auto-assignment skips them for that channel until one of their existing conversations is resolved, reassigned, or unassigned — which then triggers a drain of their queues.

The Default capacity rule cannot be deleted and its group cannot be changed — it always applies to everyone not matched by another rule.

Group details page

Opening a group from Settings → Team → Groups shows three tabs scoped to that group. Together they answer the question “what does routing look like from this team’s seat?”.

Members

The roster of users in the group, with an active/paused toggle per member. This is the same data as each member’s Groups tab, viewed from the group’s side.

A member’s eligibility for auto-assignment from this group requires the Active toggle here (technically, the underlying GroupMembership row is is_active=True). Pausing a member here is the cleanest way to temporarily remove them from rotation without changing the group’s makeup.

Queues

Lists every queue that routes to this group, in evaluation order. This is the answer to what work lands here?. Two sections:

• Primary — queues where this group is the routing target. The order shown here is the order conversations are pulled out of these queues when a member of this team’s capacity opens up — the topmost queue is drained first, and within each queue the highest-priority oldest conversation comes out first. Drag to reorder; the new order is saved as this group’s pull order over those queues. (The workspace-level queue list, which controls which queue matches a conversation in the first place, is not affected.)
• Fallback — queues where this group is configured as the fallback for another group. Read-only here; the order is owned by the primary group’s Queues tab. Conversations from these queues never go directly to this team’s members — the group only catches what the primary group of each queue couldn’t take.

Each row links back to the queue’s editor on the routing settings page.

Use this tab to debug “why isn’t my team getting any chat conversations?” — if no queue routes to the group, no work will ever arrive. Or “why is my team drowning in tickets?” — too many queues primary-target this group.

Capacity

A read-only view of the capacity rules whose group is this one, in evaluation order. The columns show the per-channel limits and the row count for each rule.

Because capacity rules apply on a first-match basis across all of a member’s groups, the rules listed here only apply to a member of this group if no earlier rule already matched them via a different group. Use this tab to spot when a member of multiple groups is silently picking up a different rule than you expected. Rows link to the capacity rule on the routing settings page.

Team member page

Opening a user from Settings → Team → Members shows tabs scoped to that user. The Groups / Queues / Capacity tabs together let you reconstruct exactly what work this individual is eligible for and why.

Groups

The groups this member belongs to. Each row has an Active toggle that controls whether the member is eligible to receive new assignments from that group.

• Active. The member is in the rotation for the group’s queues. They count toward the group’s pool for round-robin and for capacity-based pulls.
• Paused. The member stays in the group but is skipped by auto-assignment from it. Useful for short absences without removing the member from the group entirely — when they come back, you toggle it on again without losing their group history.

Columns also show how long ago the member joined the group and how long the membership has been active. Members can toggle their own group memberships; toggling another member’s memberships requires the Admin role.

Queues

A read-only view of the queues this member can pull conversations from, in the order they will be drained when the member’s capacity frees up. A queue appears here when one of the member’s active groups is the queue’s target.

Use this view when you want to know “what is the next conversation this agent will be handed?” — the answer is “the highest-priority oldest conversation in the topmost queue in this list, on a channel they have capacity for”.

Capacity

A read-only view of the single capacity rule that currently applies to this member, with the per-channel caps. Because capacity rules are first-match ordered against the member’s active groups, every member matches exactly one rule — a named rule if one of its groups applies, otherwise the Default rule, which always exists and catches everyone else.

The row links to the rule’s editor on the routing settings page.

This is the page to check when someone reports “I keep getting too many chats” or “I never get assigned anything” — the cap shown here is the ceiling the engine enforces for that person, and it is derived from their group memberships, not set per-user.

Example use cases

A few common configurations and how the rules map to them.

Billing escalations to a dedicated team, with general support as a backstop

• Group Billing, with the billing specialists as members.
• Group General Support, with everyone else.
• Queue Billing, conditions topic = billing, Routes to Billing, Fallback General Support, Stop on match off.

When Billing is fully at capacity or off-shift, the fallback lets General Support pick up the slack instead of letting the conversation sit indefinitely.

Weighted split between two regional teams

• Group Support — NA, Group Support — EU.
• Queue English support, conditions language = en, Routes to split 60% NA / 40% EU.

Each English-language conversation independently rolls 60/40 between the two teams. Over a workday the volume splits roughly along the weights.

VIP customers get higher priority but stay in the same queues

• Priority rule VIP, conditions customer segment is VIP, priority Urgent.
• Leave the rest of the queues as they were.

VIPs continue to land in the same group queues as everyone else, but they’re pulled out first whenever an eligible agent’s capacity opens up.

Cap chat-heavy agents, lift cap for the email-only team

• Capacity rule Email team, group Email, caps Chat 0, Phone 0, Email 8, SMS 0, Comments 0.
• Default capacity rule caps Chat 3, Phone 1, Email 4, SMS 2, Comments 4.

Anyone in Email gets the heavier email cap and is excluded from live channels entirely. Anyone not in Email falls through to the default.

Take an agent off rotation while keeping their group membership

On the agent’s Team member → Groups tab, flip the Active toggle to Paused for each group they are part of. They stay on the roster, keep their stats and history, and are simply skipped by auto-assignment until you flip the toggle back on. The Capacity tab will still show their applicable rule, but no new work will be routed to them.

How the pages relate

Routing settings (workspace)
  ├─ Strategy           ──► per-queue RR cursor, picks eligible member at assign time
  ├─ Queues             ──► target Group(s) + fallback   ──► Group details / Queues
  ├─ Priority           ──► stamped at escalation, drives pull order from queues
  └─ Capacity           ──► per-channel caps by group    ──► Group details / Capacity
                                                              └─► Team member / Capacity

Team member
  ├─ Groups             ◄── membership + active flag     ──► Group details / Members
  ├─ Queues             ◄── derived from active groups + workspace queues
  └─ Capacity           ◄── derived from active groups + workspace capacity rules

Next steps

• Creating Groups
• SLA Policies
• Managing Escalations
• Inbox & Views