Teams, Routing & Saved Views
Once more than two or three people work the Helpdesk, "who picks this up" stops answering itself. Teams give incoming tickets an owner automatically, respect the fact that people go to lunch, and stop one person absorbing the whole queue.
Team routing
Create routing teams for Helpdesk work
Open Teams and create a routing team
Routing is configured at workspace level. Use New team when separate queues need ownership.
Connect the team to an agent
After creating the team, choose it inside that agent’s Helpdesk settings so tickets reach the right queue.
Plan: Teams, automatic assignment, and org-wide shared views require Scale. A Growth workspace keeps the full Helpdesk, manual assignment, and personal saved views.
Teams
Create teams at Settings → Teams. A team is a routing group, not a permission boundary — anyone in your organization can still see and work any ticket.
| Field | What it does |
|---|---|
| Name | Unique within your workspace. |
| Strategy | manual, balanced, or round_robin. See below. |
| Max open tickets | Per-member cap on simultaneously-open tickets. Leave empty for no cap. |
| Default team | Where tickets go when their agent doesn't name a team. |
Point an agent at a team from the agent's Helpdesk module settings (Routing team). Tickets that name no team fall to the default team.
Assignment strategies
manual — nothing is auto-assigned. Tickets arrive unowned and someone picks them up. This is the behaviour on Growth, and a perfectly good end state for a small team that triages together.
balanced — the next ticket goes to whoever has the fewest tickets currently open. Use this for support queues, where the goal is that nobody drowns.
round_robin — ignores current load entirely and simply takes turns. This sounds worse than balanced, and for support it is. It's the right choice for sales-style queues, where each conversation is an opportunity worth distributing fairly rather than work to be shared out.
The rules underneath
Both automatic strategies share the same guarantees, and they're worth knowing because they explain behaviour that otherwise looks arbitrary:
- Only
availablemembers are eligible. Auto-assigning to someone who marked themselves away is worse than leaving a ticket unassigned, because an owned-looking ticket stops anyone else from picking it up. - Ties break on least-recently-assigned, then on user id. Without this, two members tied on load — the common case on a quiet queue — would be picked arbitrarily, and identical queue states could produce different owners run to run.
- A never-assigned member sorts first. A new joiner enters the rotation immediately instead of waiting for everyone else to cycle through.
Max open ticketsis a hard cap. When everyone is at capacity, the ticket queues unassigned and is pulled in as soon as someone closes something or comes back available. The cap is a smoothing mechanism, not a permanent backlog.- Routing happens before the ticket is written, so a ticket appears already owned rather than flickering through an unassigned state.
Availability
Each member sets their own availability per team, from the control in the Helpdesk queue. It's a durable setting, not presence detection — closing your laptop doesn't change it.
| State | Receives auto-assignments | Means |
|---|---|---|
available | Yes | Working the queue. |
away | No | Out — lunch, end of shift, leave. |
busy | No | At the desk but heads-down on something else. |
paused | No | Temporarily out of rotation while finishing current tickets. |
away, busy, and paused behave identically to the router. They're kept distinct because they mean different things to the human reading the roster, which is most of their value.
Someone on two teams has an independent position in each rotation. A busy Billing queue won't starve their turn in Technical.
Saved views
A saved view is a named set of Helpdesk filters — status, priority, agent, category, assignee. Build the filters you want in the queue, then save them.
- Personal views are just bookmarks and are available on every plan.
- Shared views are visible to the whole organization and require Scale.
- Only the author can edit or delete a view, even a shared one.
- Views are reorderable.
- Unknown filters are ignored on load, so a view saved before a filter existed still opens instead of erroring.
Views worth creating on day one:
| View | Filters |
|---|---|
| My open work | Assignee = me, status ≠ closed/cancelled |
| Unowned | Assignee = none, status = new |
| Urgent | Priority = urgent, status ≠ closed |
| Waiting on us | Status = on_you |
| Stalled | Status = on_hold |
Best practices
- Start with one team on
manual. Add strategies when the queue is actually contended; auto-assignment on a two-person team just adds a step. - Set a capacity cap before you need one. It costs nothing while volume is low and prevents the pile-up when a bad day arrives.
- Make availability part of the shift ritual. The router respects it exactly; nobody's tickets silently go to a laptop that's closed.
- Share the triage views, not the personal ones. A shared "Unowned" view is a team contract. A shared "Jayesh's tickets" view is noise.
Troubleshooting
| Symptom | What to check |
|---|---|
| Tickets arrive unassigned | Team strategy is manual; or no member is available; or everyone is at maxOpenTickets. |
| One person gets everything | round_robin ignores load — switch to balanced if the goal is even workload. |
| A ticket ignored its team | The agent's Helpdesk module names no routing team, so it fell to the default team. |
| Can't share a view | Shared views require Scale. Personal views work on any plan. |
| Can't edit a shared view | Only the author can edit or delete it. |
Next steps
- Helpdesk & Tickets — statuses, sources, and email replies.
- Webhooks — fire on
ticket.assignedto notify the new owner. - Organization & Settings — members, roles, and invitations.