# Needs You

**Needs You** is the one place Connect puts everything that requires a person: a held reply waiting for a yes, a judgement it declined to make alone, and an operational problem such as a phone line that is not healthy. It is ranked by what is at stake rather than sorted by arrival, and an item leaves when its cause clears.

- **Status:** Available
- **Audience:** both
- **In the app:** #/needs-you, #/approvals
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/glossary/needs-you/

## What qualifies

Three kinds of thing, and they are genuinely different in what you do about them. Reading the queue as though it were one kind is the usual reason it feels longer than it is.

| Kind | Example | What clears it |
|---|---|---|
| A held action | A finished reply that autonomy will not send unaided | You approve or reject it |
| A judgement | A question Connect will not answer from what it knows | You answer, or record the answer as knowledge or memory |
| An operational problem | A voice line reporting poor health; a mailbox that stopped fetching | The underlying condition ends |

The third row is the one that changes how the queue behaves. An operational item is not a task with a tick box — it is a rendering of a live condition, so it drains by itself once the condition is gone. Voice line health is the clearest example: the same health check feeds the queue for both audiences through one implementation, and when the line recovers the entry disappears without anyone acting on it.

## Why it is ranked

A chronological queue makes the newest thing the most visible, which is exactly wrong for waiting work. A held reply to a first enquiry from someone who has never written before is a different debt from a held reply on a thread that has run for a week, and the customer's experience of the two is different: a held draft is **no reply**, not a slow one — nothing has been handed to any provider and the person waiting sees silence.

Ranking is also what makes the queue survivable overnight. Work continues within the permissions each channel has been given, and what could not proceed accumulates in order of consequence rather than in order of arrival.

## Not the same as the inbox, the approvals screen, or notifications

**Conversations** — The mail. Everything that arrived, answered or not. Needs You holds only what stopped, and an item there points back into the conversation it came from rather than replacing it.
**Waiting For You** — The approvals screen, which lists held actions specifically. Approvals are one of the three kinds above, so that screen is a slice of this queue rather than a second one; an item you approve there leaves both.
**The Decision Log** — What already happened, including refusals. Needs You is forward-looking and empties; the [audit](/docs/glossary/audit/) trail is backward-looking and does not.
**Notifications** — Connect does not run a separate alert stream that you can dismiss independently. Dismissing an alert would leave the condition in place; here the item is the condition.
**A to-do list** — You cannot add an arbitrary item to Needs You. Work you want a person to do is a [follow-up](/docs/glossary/follow-up/) on the `task` channel, which no drain ever sends and which appears as work for a person on the follow-ups screen.

## Working it

1. Open the item. The material it concerns is above the decision, not on another screen.
   - Result: You can judge the answer against what is being answered.
2. Decide. Approving a held action runs it immediately through the same send boundary a person's own action uses.
   - Result: The result is recorded with the provider's own acknowledgement, and the item leaves.
3. If the reason you rejected something should change future behaviour, say so as guidance or as [memory](/docs/glossary/memory/).
   - Result: A rejection alone is a decision about one item; it teaches nothing by itself.

> **Note** An empty Needs You means nothing is waiting on a person right now. It does not mean nothing is happening — autonomous work leaves no entry here, which is the point of granting it.

## Questions

### Why did an item disappear without me touching it?

It was an operational item and its cause cleared — a line came back, a mailbox resumed fetching. Those entries are derived from live state rather than stored as tasks, so they appear and vanish with the condition.

### Can I stop something reaching Needs You?

Change the [autonomy](/docs/glossary/autonomy/) rule that holds it. Granting a channel more freedom removes held actions from the queue; setting a channel to prepare-only removes them too, but for the opposite reason — that mode does not even ask.

### Does everyone in the workspace see the same queue?

Yes. It is a workspace queue rather than a personal one, and an approval records the person who gave it, so the decision log later answers who released what.

## Related

- [Approval](https://connectbyjbrh.com/docs/glossary/approval/)
- [Autonomy](https://connectbyjbrh.com/docs/glossary/autonomy/)
- [Follow-up](https://connectbyjbrh.com/docs/glossary/follow-up/)
- [What Connect may do](https://connectbyjbrh.com/docs/autonomy/)
- [Human approval without blocking low-risk work](https://connectbyjbrh.com/research/approval-without-blocking/)

## What this page is based on

- docs-source/sources/GENERAL.md §5 — autonomy, approvals and Needs You
- docs-source/sources/GENERAL.md §4 — the app route table
- docs-source/sources/GENERAL.md §7 — the `task` follow-up channel
