> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Troubleshooting: inbox assignment stuck pending, and auto-close timing > Diagnose an inbound digital conversation that holds in pending, one that opens but never claims an agent, or an auto-close sweep that fires too soon. Match the symptom to its cause, check the owning control, and fix it in place. # 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](/inbox/routing-rules) and [digital queues](/inbox/digital-queues) decide who gets it, [agent presence](/concepts/agent-presence-lifecycle) decides who is eligible, and [auto-close](/inbox/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](/inbox/pending-replies) — 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](/inbox/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](/inbox/digital-queues) 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](/inbox/pending-replies) 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 | *** ## See also * [Pending replies](/inbox/pending-replies) — the supervisor queue that gates outbound replies * [Digital queues](/inbox/digital-queues) — skill-match, SLA, overflow, and live stats on the digital ACD * [Auto-close](/inbox/auto-close) — tenant-owned idle-window configuration and the guardrails * [Routing rules](/inbox/routing-rules) — the priority-order auto-assign evaluator * [Agent presence lifecycle](/concepts/agent-presence-lifecycle) — the five states every assignment checks