Working the Needs You queue, end to end

Needs You is the single list of things only a person can settle: held actions, questions Connect could not answer, and operational problems such as a mailbox that stopped fetching or a phone line that is unwell. It is ranked by what the delay costs rather than by arrival time, every item names the decision it wants, and each one drains by itself once its cause is gone.

Status: Available What this means
Audience: both
In the app: #/needs-you, #/approvals, #/follow-ups
Last verified: 2026-09-10
Product version: 6.3.2

The chain, for one pass#

Trigger — a person opens Needs You, or the badge count changes while they are elsewhere in the app.
User or external event — the items were created earlier by the engine, by a provider failing, or by a health check.
Authentication and workspace resolution — the session resolves to one workspace; the list is that workspace's and nothing else.
Ingest — nothing is fetched from outside. Voice line health is read from voice_engine.line_health at render time rather than stored as a separate to-do.
Canonical record — each entry points at the record it is about: a thread, a call, a mailbox, a follow-up.
Reasoning — the ranking. Items are ordered by cost of delay, so a first-time enquiry outranks a week-old thread that has already been answered twice.
Knowledge, memory and rules — an item shows what Connect already knows, so the decision is made with the same context the draft was written with.
Autonomy and approval — for held actions this is the decision itself; for a question, it is guidance the engine will use next time.
Action through a provider — only for the items that are approvals; an operational item is settled by fixing the cause, not by sending anything.
Result — the item leaves the list. Nothing is archived into a second inbox.
Relationship, timeline and memory — decisions and guidance land on the thread, the person or the memory tier they belong to.
Audit, usage and Needs You — every decision goes to the decision log, and the queue re-ranks what is left.

The four things you will find in the list#

Stage	What you see	What changes	What can fail
A held action	A finished reply, message or call request with the thing it answers	On approval it goes through the shared send boundary; on rejection the engine stops re-preparing it	Approving without reading — the draft may be answering a message the customer has since replaced
A question	Something Connect could not settle from knowledge or memory	Your answer becomes guidance and, if you say so, a durable memory	Answering in the item only — the answer helps this thread and teaches nothing unless it is written as memory or a standing instruction
An operational problem	A mailbox that stopped fetching, a line that is unwell, an integration that disconnected	Nothing until the cause is fixed; the entry drains on its own once it is	Dismissing it as noise — this is the class that silently stops work arriving at all
Work for a person	A follow-up on the `task` channel, shown as 'For a person to do'	It is completed by a person and nothing else	Waiting for Connect to do it: no drain ever sends a `task` follow-up, by design

Working it, in order#

Take the operational items first, before any drafts.
Result Fixing a mailbox that stopped fetching changes what the rest of the queue should contain. Approving replies while inbound mail is not arriving is answering half a conversation.
Work the held actions in the order shown rather than by date.
Result The ranking already encodes what the delay costs. Re-sorting by time puts the oldest thread first, which is usually the least urgent one.
For each question, decide whether the answer is about this thread or about the business.
Result Thread-level answers stay guidance; business-level answers become memory at the right tier and stop the question recurring.
Finish with the task follow-ups, which are yours to do rather than yours to decide.
Result They leave the list when you complete them, and the follow-ups screen keeps the ones with a date still ahead.

A pass that ends with an empty list means every item's cause has cleared or been decided. It does not mean nothing is wrong: the queue only carries what something knew to raise. Needs You is empty and something is wrong covers the gap deliberately.

What triage does not do#

It does not change autonomy: Deciding twenty held replies leaves the mode that held them exactly as it was. The volume of the queue is the signal that the mode is wrong.
It does not silence a cause: There is no dismiss that hides an operational item while the cause persists; it would come back on the next render, because the entry is derived rather than stored.
It does not summarise itself: The count is not a health score. Ten trivial approvals and one dead mailbox both show as items.
It does not belong to one person: The queue is the workspace's. Whoever decides is named in the decision log, so a shared list still has individual accountability.

Questions#

Why is the list not in date order?

Because arrival time is a poor proxy for importance. A first reply to somebody who has never been answered costs more to delay than the fourth message on a thread already in progress, and a chronological list buries the first behind the second.

Can I clear an operational item without fixing it?

No, and that is deliberate. Those entries are derived from the state that caused them — a mailbox's health, a line's health — so hiding one would only hide it until the next render. Fixing the cause removes it.

Does the Connect Assistant work the queue for me?

It can list what is waiting and approve or reject specific drafts when you ask it to, using the same tools you would. It cannot widen its own authority: its rights stay narrower than a person's, and an operational fault still needs the underlying cause dealt with.