Queue configuration

Queues are broad, top-level categorisations of tickets — Sales, Support, Tasks and so on. Each queue has its own permissions and its own outgoing mailbox, so notifications and emails about a ticket are sent from the address tied to its queue: a ticket in the Sales queue would go out from sales@example.com, a ticket in Support from support@example.com. Use queues for the small set of buckets the whole organisation recognises; for finer-grained categorisation within a queue, use perspectives for dynamic groupings and watchlists for hand-picked sets.

The queue admin page is at Settings → Queues (in the Workflow section of the Settings menu) and is admin-only.

The queue list

Each row shows the queue name plus a few chips:

1. Ticket count — how many tickets currently sit in this queue.
2. Inbox for: <mailbox> — appears when a mailbox has been configured to route incoming tickets directly into this queue, naming that mailbox (or mailboxes). Most queues will not show this chip; the routing is opt-in per mailbox and is set up in Mailbox setup, not here.

The internal Drafts queue is hidden from this list — it holds in-progress unsent tickets per user and is managed automatically by Tickiti, not by an admin.

Editing a queue

Click a queue to view its current settings, then click Edit to change them. The fields are:

1. Name — how the queue appears in the UI everywhere else.
2. Track resolutions — when on, closing a ticket in this queue prompts the closer to pick a resolution category (Resolved / Unresolved / No response / Advice given / Other reason). Powers the Resolutions report. Only worth turning on for queues where you actually measure outcomes; needs the has_resolution_tracking plan capability.
3. Outgoing mailbox — the mailbox used as the From address when Tickiti sends emails about tickets in this queue. Needs to be set; see Mailbox setup.

The detail pane also shows read-only counts (total tickets, inbox-for mailboxes, whether perspectives reference it).

Move and Delete

1. Move — relocates all the tickets currently in this queue into another queue. Useful when you are about to retire a queue, or restructuring teams. The dialog tells you exactly how many open and closed tickets will move.
2. Delete — removes a queue. Only allowed when the queue holds no tickets and no perspectives or other configuration references it; the button stays disabled with an explanatory tooltip until those constraints are met. The built-in Inbox queue cannot be deleted.

Adding a queue

1. Click Add at the top of the queue list.
2. Set the name.
3. Pick the default outgoing mailbox.
4. Optionally tick Track resolutions.
5. Click Save.
6. Use User admin to grant queue access to staff who need it — new queues start with no permissions until you set them. See Queue permissions for what each permission level allows.

The number of custom queues you can have is capped by your plan; built-in queues do not count against the cap. If the cap is reached the Add button shows the cap and the path to extend it.

Inbox

The built-in Inbox queue is the default landing place for new customer tickets unless an explicit mailbox routes them somewhere else. It cannot be deleted. You can rename it (most teams keep the name) and you can change its outgoing mailbox; from there it behaves like any other queue.

If you want a different routing — for example tickets from your sales@ mailbox going straight into a Sales queue rather than landing in Inbox first — configure the routing on the mailbox itself; see Mailbox setup.

Picking the queue set

A small number of well-named queues is easier to manage than many fine-grained ones. Start with a queue per responsibility, not per topic — e.g. Support + Sales + Tasks, rather than one queue per product line. Use perspectives and hashtags to slice by topic within a queue.