​

The routing-claim election lifecycle

The group messaging model separates fan-out (one operation reaching many recipients) from thread assignment (one conversation reaching one owner). That page stops at the border of assignment; this one is what happens on the destination side. A conversation routed to your team is elected — one claim wins, every competing claim loses, and the winner owns the work item through a lifecycle that runs open → pending → resolved. Nothing else about routing makes sense until that primitive is pinned down. The primitive has a strict rule the whole platform enforces: the claim module never runs two competing claims on one work item at the same time. Configuring a surface as if a label were routing — or expecting a group send to carry thread semantics back — both trace to the same mistake, which is treating something that is not a claim as if it were one.

​

1. The three claim families

Three things participate in answering “whose is this conversation.” They look similar in the dashboard but are different families, and only two of them are routing at all. Conversations claim (inbox digital queues) — a conversation arriving on a digital channel (chat, email, SMS, WhatsApp, web chat, social) lands in a digital queue under /api/v1/inbox/digital-queues. The claim is the assignment: routing elects one agent, binds the conversation to that agent, and holds it through the disposition lifecycle. Open means assigned and awaiting first reply, pending means waiting on the customer or on a teammate’s follow-up, and resolved means the claim is discharged. Apply a manual override with POST /conversations/:id/disposition; read the open/pending/resolved distribution from the dispositions stats endpoint. Voice-ring claim — an inbound call offered to a ring group is elected by the ring strategy you configured on the group: first-available (ring the first idle member), round-robin (rotate the starting point per call), or fewest-calls (elect the member with the fewest answered calls). The election is atomic with the ring itself — the strategy names one member, and that member’s endpoint holds the call for the acceptance window. No second member’s endpoint can hold the same call. Label (annotation) — a label is not a routing claim. It is a tag applied to already-assigned work: reporting filters, QA scorecards, saved views. Attaching a label adjusts audit metadata on the conversation; it never moves the conversation between owners, queues, or lifecycle states.

​

2. Election primitives

Each routing family elects through different machinery, and the machinery matters because it defines what a loss looks like when two claims race. Inbox: presence + capacity ledger. The digital router reads the eligibility underneath the queue. Agent presence — the five-state machine in Agent presence and aux-code lifecycle — decides who is even in the election pool (available is eligible; busy, wrapup, paused, and offline are excluded variously by channel). On top of presence the router holds a blended capacity ledger: the omnichannel slot reservation described in Omnichannel capacity and reservation model reserves one slot atomically, refuses the reservation when the ceiling is saturated, and releases once the assignment row is durable. Election loss mode: the candidate keeps its slot free; the conversation goes to the next candidate, an overflow queue, or the unassigned pool. Voice ring: strategy election. A ring group elects one member per call by the configured strategy, in lockstep with the ring attempt — candidates are pre-ordered per call, the highest-priority candidate whose presence allows eligibility wins, and the call is offered to exactly that member. Election loss mode: the ring group does not double-offer; the call rotates to the next elected member on timeout or decline. Neither primitive is a tag. Both terminate in a durable assignment row that every read surface — inbox views, the wallboard, reporting — agrees on because there is only one row to agree about.

​

3. Why a label is never routing truth

Labels and claims have different binding semantics. A claim is lifecycle-bound — it exists from assignment to resolution and its state changes the conversation’s behavior: SLA timers run against open, pending parks the SLA clock, resolved discharges the ownership. A label is static — it exists whenever you stick it on, and conversing state, ownership, and SLA behavior are indifferent to whether the label is present. Misuse shows up in two predictable places. In QA: an evaluator applies a disposition label to score or categorize a conversation and the operation seems to “route” — but dispositions write annotation metadata for review distribution, not assignment rows. Dispatch never reads the label store. In dispatch: an operator assumes applying a queue-named label moves the conversation into that queue. It does not; only the conversations claim — an election through presence and capacity — moves ownership. If you find a workflow that expects a label to change who owns an item, re-read the disposition lifecycle under the Inbox API reference and use the assignment surface for the ownership change the workflow actually wants.

​

4. MMS group fan-out versus shared-conversation

The destination primitive also decides which channel shape a group interaction takes. Pick the destination first, then let that pick the channel: Carrier evidence runs one way only: SMS and MMS have no joint thread object, so group MMS is a fan-out of per-recipient copies and the replies you get back are claims on individual threads again. Outbound still exits exclusively via the Devotel wholesale softswitch in either channel choice — election governs inbound ownership, never outbound termination.

​

5. Where this page sits

Adopt this lifecycle as the destination-side companion to the fan-out page:

• Group messaging model — resolves fan-out versus thread on the send side and hands the ownership question to this page.
• Agent presence and aux-code lifecycle — the presence half of the inbox election pool.
• Omnichannel capacity and reservation model — the atomic capacity half of the same election.
• The ACD queue model — queue membership, skills, and FIFO dispatch feeding the same presence + capacity election.
• The call-quality evaluation lifecycle — where disposition labels actually drive value: QA distribution, never dispatch.
• Omnichannel queue routing for digital channels — the operator guide for the digital queues the conversations claim lands in.
• Set up and run voice queues — ring-group strategies and queue operation.