Configuring the agent desk's queues

A desk queue in Kav is department-scoped, not channel-scoped — a resident's conversation lands in the right department's queue regardless of whether it started on the widget, Telegram or WhatsApp, and an agent doesn't need to know which channel it came from to answer it. Configuring a queue is five decisions.

1. Slug and department — one of them locks

The slug is the queue's stable identifier. The department code is fixed once the queue is created — repointing an existing queue's slug to a different department would silently re-attribute every historic handoff ever routed through it, so the server refuses that change outright. The edit form shows the department as read-only text rather than as a field you could fill in wrong and then have rejected.

2. Display names, in both directions

A queue carries a display name and a Hebrew display name as two separate fields, both real inputs rather than one field and a translation layer — because a queue name is often a department's own name, and that's not something to machine-translate.

3. Takeover mode — how the bot behaves once a human is involved

• BotOff — the assistant steps back entirely once a person takes the conversation.
• BotSuggests — the assistant offers a draft reply the agent can accept, edit, or ignore.
• BotDrafts — a stronger form of the same idea, for a department that wants more of the drafting done for them.

Pick this based on how much your agents actually want machine help mid-conversation, not on a default — different departments legitimately want different answers here.

4. A sensitivity ceiling

maximumSensitivity caps how sensitive a conversation this queue may ever be trusted to hold, using the same seven-class scale (Public through SpecialCategory) that governs every capability's own data. Unlike a personal clearance, Public is a legitimate answer here — a queue can be deliberately scoped to only the least sensitive conversations.

5. Active, and what "off" actually means

The active checkbox only ever answers one question: should this queue be receiving handoffs right now. Underneath, the server maps that onto a real three-state status — a brand-new queue left inactive stays Draft (never yet opened), while an existing queue that's turned off becomes Disabled (opened, then closed). That distinction isn't invented by the form; it's the honest label for two genuinely different histories, and the checkbox doesn't have to know which one applies.