Troubleshooting: inbox assignment stuck pending, and auto-close timing

A digital (non-voice) conversation crosses three tenant-owned surfaces between arrival and an agent: routing rules and digital queues decide who gets it, agent presence decides who is eligible, and auto-close decides when an idle thread closes. When the thread appears stuck — held in the pending lane, sitting open with no owner, or swept before anyone claimed it — the diagnosis is always one of a handful of causes on those four surfaces. This page groups the symptoms so you check the right control first. Everything below is tenant-owned configuration. Nothing here touches carrier or provider behaviour — inbound routing and lifecycle decisions are your workspace’s own settings, evaluated on your workspace’s rows.

Verify the surface first

Two quick checks narrow the cause before you open the tables:

Split pending meaning. An inbound thread sitting in pending while you expect assignment is a routing/queue/presence issue — work the first table below. An outbound reply you composed as a gated agent that never reaches the customer is a supervisor-decision hold in the Pending replies queue — work that table instead.
Read the digital-queue stats. GET /api/v1/inbox/digital-queues/stats returns per-queue backlog, oldest_wait, sla_breach_count, agents_available, and virtual_holds. A queue with nonzero backlog and zero agents_available is a presence/skills issue; nonzero backlog with high sla_breach_count and a positive agents_available means eligible agents have no headroom under their per-channel cap; an empty backlog means the conversation never joined this queue — check routing rules and channel-match.

Inbound conversation holds in pending (never assigns)

A new inbound conversation starts unassigned and stays that way until routing rules or a digital queue place it. Every conversation this page handles was read as an inbound lifecycle issue — the pending state here is the inbox’s unassigned lane, distinct from an agent’s pending reply.

Symptom	Cause	Check	Fix
Thread sits unassigned; no queue picked it up	The queue on that channel is disabled, or no queue’s `channel` matches the inbound conversation’s channel slug	Read `GET /api/v1/inbox/digital-queues/stats` — empty `backlog` across all queues; open Inbox → Settings → Digital queues and compare enabled queues’ channels	Re-enable the queue, or add/fix a queue whose channel covers inbound. Routing rules are checked as the fallback below
New conversations land in `pending` with no queue claim	A routing rule’s assign action found no eligible target (named user offline, pool empty, or unmatched skills)	Read the queue’s decision trail or re-run the rule’s dry-run in Inbox → Settings → Routing with a real sample conversation; check presence for the named targets in the team view	Widen the pool, fix the target, or let a digital queue hold-and-retry instead of a direct assign
Queue shows waiting set with zero available agents	The `no_skilled_agents` overflow fired, or queue skills exceed every agent’s profile	`GET /api/v1/inbox/digital-queues/stats` shows `backlog` > 0 and `agents_available` = 0; check the conversation’s trail in `GET /api/v1/inbox/routing-decisions/:conversationId`	Cover the queue’s required skills on at least one agent’s profile, or relax the queue’s skill list. Overflow to `routing_rules` when nobody qualified
Conversation waits but never assigns despite available agents	Eligible agents are at their per-channel conversation cap — assignment only considers agents with headroom	`stats` shows positive `agents_available` but nonzero `backlog` and rising `sla_breach_count`	Raise the per-channel cap, add agents to the pool, or broaden the queue’s required skills

The routing priority dimension sits beside queues as a second evaluator. A broad rule with a low priority number shadows every specific rule below it, and a saved rule whose tag or segment condition references a vocabulary the workspace never defined matches silently-nothing. Inbox → Settings → Routing’s dry-run panel is the fastest arbiter — re-run it with a copy-pasted sample conversation.

Conversation opens but the claim never fires

Assignment can look correct on arrival yet never complete — the conversation renders open with an empty assignee, or holds in the queue’s waiting set past the SLA deadline. These causes are presence-side or election-side, not routing-side.

Symptom	Cause	Check	Fix
Conversation assigned to an agent who never sees it	The agent’s worst-case presence is `offline` — the claim pool skipped them; the row reads open but unowned	Read the agent’s worst-case state; confirm they are not `offline` or auto-logged out by the idle-logout sweep	Have the agent log back in. Confirm their membership is `available` on the queue. The assignment then holds
Conversation assigned but the agent was on a voice wrap	Their `wrapup` presence caps digital eligibility to the smallest bracket, so co-claimed digital load caps out fast	Check the agent’s state from the team view after each call ends	Wait out the wrap-up window or submit the disposition early; a callback writeback also clears wrapup immediately when taken
Agent is `paused` but the voice lobby still shows them as eligible	`paused` never gates digital claim — digital assignment runs independently of the pause reason	Look at the voice lobby’s eligible list, not necessarily the digital-eligibility pool	Digital assignment can legitimately claim a paused agent. If the intent is for paused agents to hold no digital work, don’t use `paused`; rely on cap-headroom instead
Queue’s waiting set never promotes to assigned	The scheduled sweep re-arms `hold` queues and re-evaluates the deadline; a saturated `max_queue_depth` re-sheds via `routing_rules`	Read the queue’s overflow action and depth; check whether the conversation’s trail shows a `queue_full` or `sla_breached` reason	Change the action or raise the depth; pick `hold` only when an indefinite wait is acceptable
Assignment disappeared after a reassign loop	The claim election rejected concurrent claims — two eligible agents attempted simultaneously, one wins, one loses	Read the conversation’s decision trail; confirm the claim’s winner	Normal and deliberate — the conversation is owned by exactly one agent; no action needed

Auto-close closes too soon, or before a claim window fires

Auto-close is tenant-owned and ships off; when enabled, the sweep closes idle threads regardless of claims. These causes are mistakes in the idle-window or status-scope configuration, not a misfiring sweep.

Symptom	Cause	Check	Fix
A thread closed while an agent was still drafting the reply	Typing is not a message. Only an actually-sent message restarts the idle timer, and drafts never qualify	Confirm the draft was not sent before the window aged the thread; check the last sent message timestamp	Reopen the thread and the reply still sends. Long idle windows make this rare; if recurring, lengthen the window, or encourage agents to send deliberately rather than hold drafts
The auto-close slider clamps windows suspiciously short	Fractional and out-of-range settings are clamped to 1–90 days on save; a manual edit to 0 or a fraction felt like “as soon as possible” but still swept in a day	Open Inbox → Settings → Auto-close stale conversations and confirm the saved window reads a whole number in range	Re-save the window to the intended value; the sweep fires at most 10 minutes later
Threads closed despite the toggle reading off	The off-save failed silently and the old on-config was still live when the sweep ran	Re-open the settings page and confirm Enable auto-close reads off; check the audit trail entries (`conversation.auto_closed_stale`) — all entries predate the last successful off-save	Save off again and confirm. The audit trail distinguishes platform-decision closes from agent closes
A thread you expected to be safe got swept	`pending` reply approvals and AI answers restarts the idle timer, but status scope `open` + `pending` includes both, not just one	Check which statuses are selected in the auto-close settings	Narrow the scope to the intended statuses. For threads that genuinely rest on the supervisor queue, accept that cleared approvals hurry the timer to restart
The same class closes too fast only on one channel	The queue this channel routes to has no headroom and a waiting-set SLA gate; auto-close sees a stale `open`/`pending` row	Match which channel the thread came in on; check that channel’s queues’ skill match and caps	Fix the queue’s eligible-agent pool before retuning auto-close — otherwise the sweep just removes the same misassignment class

Pending-replies holds outbound text (supervisor gate)

When agents’ replies submit as gated: true and never reach the customer, the thread stays open with no outbound row — inbound routing and auto-close are bystanders to that. Work the Pending replies queue from a supervisor seat.

Symptom	Cause	Check	Fix
A reply never reaches the customer with `gated: true` submitted	The approval gate requires a supervisor decision — the reply is deliberately held	Open Inbox → Pending replies from an owner/admin/supervisor — any row for the conversation is the held reply	Have a supervisor approve or reject the row; on approve the exact body dispatches on the conversation’s channel
An approval failed with the row still pending	The dispatch step errored — the conversation closed, the provider was down, or a send-time validation tripped	Read the per-row error the approve click returned	Fix the cause and approve again, or reject the row instead. A failed approve never half-sends
Two supervisors tried to decide the same row	Both actions reject a row already decided — the second supervisor’s attempt fails, the first supervisor’s decision stands	Re-list the queue; the row should be gone	Pick one supervisor per queue and work it deliberately; never decide rows in two tabs
Owner keeps landing in the queue they can’t approve	Only the workspace owner is never gated — an owner-submitting row never queues	Confirm the submitting agent’s role is owner; admin or supervisor seats still gate	The submitting agent needs a supervisor decision for their composed reply like any gated member

Reference

Troubleshooting: inbox assignment stuck pending, and auto-close timing

Troubleshooting: inbox assignment stuck pending, and auto-close timing

Verify the surface first

Inbound conversation holds in pending (never assigns)

Conversation opens but the claim never fires

Auto-close closes too soon, or before a claim window fires

Pending-replies holds outbound text (supervisor gate)

See also

​Troubleshooting: inbox assignment stuck pending, and auto-close timing

​Verify the surface first

​Inbound conversation holds in pending (never assigns)

​Conversation opens but the claim never fires

​Auto-close closes too soon, or before a claim window fires

​Pending-replies holds outbound text (supervisor gate)

​See also

Troubleshooting: inbox assignment stuck pending, and auto-close timing

Verify the surface first

Inbound conversation holds in pending (never assigns)

Conversation opens but the claim never fires

Auto-close closes too soon, or before a claim window fires

Pending-replies holds outbound text (supervisor gate)

See also