Queues and Teams

Last verified against the codebase: 2026-07-25.

What it is

A queue is a named bucket that tickets land in, with its own members, routing rules, assignment policy, SLA targets and alerts. A team is a named group of people that queue access can be granted to in one move.

Together they decide three things: where a ticket goes, who works it, and who can see it.

Concepts

Roles and permissions

The role hierarchy is platform administrator > MSP administrator > MSP technician > organization administrator > power user > CUSTOMER`.

Note that MSP technician outranks organization administrator. Every rank floor below is “this role or higher” against that order, so a technician clears an organization administrator floor.

Beyond the rank floor, each queue action resolves a per-queue authority:

Walkthrough — creating a queue

MSP portal: Settings → Queues. Organization portal: Settings → Ticket Queues. Both render the same page against your own account’s queues.

1. Click New Queue. The editor opens on the General tab.
2. Give it a name — unique within the organization — plus an optional description, colour and icon.
3. On Access, choose EVERYONE or RESTRICTED. Leave it on EVERYONE unless you have a reason; see section 5.
4. On Assignment, pick a method and decide whether auto-assign is on.
5. On SLA, set response and resolution targets in minutes, and whether the clock counts business hours only.
6. On Alerts, choose which of the three notifications the queue’s members receive.
7. Save. Members and Rules tabs appear once the queue exists — you cannot add either before there is a queue to attach them to.

To make it the fallback for unrouted tickets, turn on Default queue. The previous default is cleared in the same operation, so there is always at most one.

Walkthrough — restricting a queue

RESTRICTED hides the queue and the tickets inside it from people who have no route to it.

1. Open the queue, go to Access, set the mode to Restricted.
2. Add the people and teams who should reach it. Granting a team grants every current and future member of that team.
3. Save.

After that, the queue is reachable by:

• its active members,
• anyone with a direct grant,
• anyone in a granted team,
• organization administrator and above within the owning account (the admin bypass),
• the requester and assignee of any individual ticket, always.

Admins are never partitioned. An organization administrator can always see their own account’s restricted queues. They could grant themselves access in two clicks, so hiding it would be false security and a lockout hazard.

A client can never hide from its MSP. A queue owned by an account that your account services stays visible to your staff — the MSP operates the helpdesk. The reverse does not hold: an MSP’s restricted queue binds its own technicians as well as client viewers.

Walkthrough — sharing a queue with a client

This is the MSP-side journey. It needs authority full, which means the queue belongs to your account.

1. MSP portal → Settings → Queues, open the queue.
2. Go to Sharing. The tab only appears when there is somewhere to share to — a managed client organization, or a share already in place.
3. Pick a client organization from Share with a client organization…. The share is created immediately, in EVERYONE mode.
4. Set the share’s access mode:
   • Everyone — every user in that client organization can see the queue and file into it.
   • Restricted — only the people and teams granted on the client side.
5. If you chose Restricted, add client-side grants. Both you and the client’s own admins can manage them.

The client sees the incoming share at Settings → Ticket Queues, in the “shared with your organization” section, where their admins can adjust the client-side access mode and grants for their own organization.

The target must be a managed client. Sharing to an organization your account does not service is refused with Target organization must be a managed client organization. A queue cannot be shared to its own organization.

Teams

MSP portal: Settings → Teams. Organization portal: Settings → Teams.

A team is a named, coloured group of people in one organization. Its only built-in consumer today is queue access grants, but nothing about the model is queue-specific.

• Membership is bounded by the tenant. A person can only be added if they hold an active membership in the team’s organization, or a membership in that organization’s account.
• Names are unique per organization. A collision returns A team with this name already exists.
• Deleting a team cascades. Its memberships and its queue grants go with it. The people themselves are untouched.
• Deactivating a team revokes its grants’ effect. Grant matching requires isActive: true on the team, so switching a team off removes the access it conferred without deleting anything.

Mirroring a directory group

If your identity provider syncs groups over SCIM, a team can mirror one:

1. Open the team, choose a directory group under Directory group.
2. Save. Membership reconciles immediately and again on every SCIM membership change.

While a team is linked, manual member edits are refused with This team mirrors a directory group — manage membership in your identity provider. Unlinking freezes the current membership in place rather than emptying it. One group can back only one team; a second attempt returns That directory group is already linked to another team.

Routing rules

Rules live on the destination queue: open the queue → Rules. Rules are evaluated in descending priority; the first match wins.

Match modes: EQUALS, NOT_EQUALS, CONTAINS, STARTS_WITH, ENDS_WITH, IN_LIST, REGEX.

REGEX patterns are validated before use: patterns over 200 characters, and patterns matching known catastrophic-backtracking shapes such as (.*)+ and (.+)+, are rejected.

CUSTOM is rejected at the API with Custom-field matching is not yet supported — tickets have no custom fields to match against. This is deliberate: tickets have no custom-field storage, so a CUSTOM rule would be saved and then silently never fire.

When no rule matches, the ticket falls to a default queue — the ticket’s own organization’s default first, and only if it has none, the servicing MSP’s.

An MSP’s rules apply to its clients’ tickets. Rule evaluation spans the ticket’s own organization and the organizations of every account servicing it, because an MSP’s queues and rules live in the MSP’s own organization.

Reorder rules with the up/down controls; the whole ordered set is submitted at once, so a partial list is rejected.

Assignment

Auto-assignment only runs when the queue’s Auto-assign toggle is on. Set Max active per agent to stop the picker handing work to someone already at capacity; leave it empty for no cap. Members carry a priority (higher means more work) and free-form skills tags.

You do not have to trigger it.

Moving a ticket between queues

Open the ticket. In the MSP portal the queue is a card in the header strip alongside Assigned To; in the organization portal it sits with the status, priority and assignee controls. Choose a different queue and the move applies immediately.

The picker lists the queues available for the ticket’s organization, not yours — so an MSP technician working a client ticket sees the client’s own queues, their MSP’s queues, and anything shared into that organization. Queues reached through a share are labelled with the owning organization.

Every move is recorded on the ticket’s activity timeline as “Moved from queue A to B”, with the acting person and timestamp. The trail stores queue names, not ids, so it stays readable after a queue is renamed or deleted. Re-assigning a ticket to the queue it is already in records nothing.

If the target queue has auto-assign on, the move also picks an agent.

The control is read-only below organization administrator; power user and CUSTOMER see the queue name as text.

Ticket visibility

Restricting a queue restricts its tickets. The rule narrows what you can already reach — it never widens it.

• A queue owned by your own account partitions you: RESTRICTED hides its tickets unless you are a member, granted, an admin, or the ticket’s requester or assignee.
• A queue owned by any other account never hides a ticket the tenant boundary already reaches. Both halves of that matter: a client cannot hide its tickets from the MSP that runs its helpdesk, and an MSP cannot make a client’s own data vanish by routing it into an MSP-internal queue.
• Unqueued tickets are always visible.
• Requesters and assignees always see their own tickets, whatever queue they sit in. An end user’s ticket never disappears from their portal because staff moved it.

The same rule is applied by the MSP ticket surface as by the ticketing service, from one shared implementation, so the two can never drift apart.

Notifications

Three queue-level toggles, all on the Alerts tab, all delivering in-app notifications to the queue’s active members:

• The person who performed the action and any auto-assigned agent are excluded from the new-ticket alert — the agent gets a dedicated assignment notification instead.
• SLA warnings are raised separately for the first-response clock and the resolution clock, and each is raised at most once per ticket.
• The unassigned nag fires once per ticket, ever. Set the timeout in minutes next to the toggle; the sweep runs every 10 minutes.
• Inactive members and deactivated people never receive any of them.

Every queue setting

Plan tiers

Queues and teams are not plan-gated. Every capability in this document — queues, members, routing rules, access modes, grants, teams, and MSP→client sharing — is available on every tier including Free.

Two adjacent capabilities are gated, and are documented in their own guides:

The per-queue SLA fields in section 13 are not covered by slaManagement — they belong to the queue and are available on every tier. Mirroring a team from a directory group needs SCIM provisioning to be running, which in practice means an Enterprise plan.

Troubleshooting

Limits and known behaviour

• One share per queue per client organization. Re-sharing updates the existing share rather than creating a second one.
• Grants are matched by identity, not by organization. A grant’s organizationId decides who may manage the grant, not where it applies.
• A team grant follows the team. Adding someone to a granted team gives them the queue immediately; removing them takes it away.
• Deactivating a queue does not move its tickets. They stay where they are and remain visible; the queue simply stops appearing in pickers.
• route-ticket and assign-ticket have no bulk form. Both act on one ticket per call.
• Queue AI settings are configuration for the AI agent, documented here for completeness; the agent’s own behaviour is covered by the AI guide.
• Queue-level businessHours is a per-queue JSON schedule, separate from the organization-wide business-hours calendars behind the slaManagement gate.
• Mobile. Queue and team administration is web-only today.