# Held drafts

A held draft is a finished reply that Connect wrote and did not send, because the autonomy rule for that channel says a person decides. It waits in Needs You with the message it answers, the recipient sees nothing at all, and it goes out unchanged the moment somebody approves it.

- **Status:** Available
- **Audience:** both
- **Channels:** email
- **In the app:** #/needs-you, #/inbox
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/email/held-drafts/

## What holds a reply

Four things hold a reply, and they are checked in this order. Knowing which one is holding yours is most of the work of releasing it.

| Hold | Set where | Releases when |
|---|---|---|
| Autonomy is `ask_before_send` | Per channel, or narrower — one contact, one mailbox | A person approves it |
| Autonomy is `draft_only` | The same place | Never automatically: this mode deliberately does not even ask |
| The daily allowance is spent | The workspace plan | The allowance resets, or the plan changes |
| The recipient is suppressed | Suppression, unsubscribe or do-not-contact | The suppression is cleared, if it is one that may be |

> **Note** `draft_only` and `ask_before_send` look identical on the Conversations screen and are not the same thing. `ask_before_send` puts the reply in front of a person; `draft_only` writes it and stops, on purpose, so that a workspace can watch what Connect *would* say without anyone having to keep saying no.

Autonomy resolves narrowest-first over four scopes — contact, endpoint, channel, workspace — so the mode that held this particular reply may not be the one shown on the channel. The narrowest rule that applies is the one that decided.

## What the recipient sees

Nothing. A held reply has not been handed to any provider, so there is no message in flight, no read receipt, no delivery attempt and nothing in your sent folder. This matters when a customer is waiting: a held reply is not a slow answer, it is no answer, and the clock the customer is counting is still running.

That is also why the queue is ranked rather than chronological. A held reply to a first-time enquiry is a different kind of debt from a held reply on a thread that has been going for a week.

## Releasing one

1. Open Needs You and pick the item. The original message is above the reply, not on another screen.
   - Result: You can read what is being answered without losing the answer.
2. Edit if you want to. The subject, the body and the recipients are all editable; the mailbox it will be sent from is not, because that was decided by the mailbox's role and the thread it belongs to.
   - Result: Your edit is what gets sent — Connect does not re-write over it.
3. Approve.
   - Result: The send runs immediately through the same boundary a person's own send uses, and the result is recorded with the provider's own acknowledgement. Until that acknowledgement arrives the state is *uncertain*, not *sent*.

Rejecting instead of approving records the rejection against the thread, and the engine does not immediately write the same reply again. If the reason is something Connect should know in future, say so as guidance on the thread or as a memory — a rejection on its own is a decision about one message, not a lesson.

## Both audiences, one queue

Needs You is the same queue for the Owner and for a customer workspace, drawn from the same implementation, and it holds more than replies: refusals, approvals on other channels and operational problems such as voice line health all escalate into it. Every entry drains by itself as its cause clears, so an item that disappears without anyone touching it usually means the condition behind it resolved.

The commercial difference is the only difference. A customer's throughput is bounded by their plan's allowance; the Owner has no plan and no gates. The mechanism holding the reply is identical.

## What can go wrong

**It is not in Needs You** — It was held by `draft_only`, which does not queue anything for approval. Change the mode, or send it from the conversation.
**Approving does nothing visible** — The allowance was already spent. The approval is recorded and the send waits; the item stays until it goes.
**Approving fails immediately** — The recipient is suppressed. The suppression is shown with its origin; a do-not-contact entry is not cleared casually and the Connect Assistant cannot clear one at all.
**It is stale** — The thread moved on while it waited. Regenerating gives the model the newer messages; editing does not.
**It went out while you were reading it** — Someone else approved it, or autonomy on a narrower scope permitted it. The decision log names who or what released it.

## Questions

### Does a held draft expire?

It is not deleted, but it does go stale: if the customer writes again, what you approve is an answer to the older message. The queue shows when the thread has moved on so you can regenerate instead of sending something that reads as though nobody was listening.

### Can I hold replies for one customer only?

Yes. Autonomy resolves at four scopes and the narrowest wins, so a rule set against one contact overrides the channel's. That is the usual way to handle an account where every word matters without slowing down everything else.

### Who can approve?

Any workspace member with permission to send on that channel. The approval is recorded against the person, and the decision log answers 'who released this' months later.

## Related

- [What Connect may do](https://connectbyjbrh.com/docs/autonomy/)
- [Approving and rejecting a draft](https://connectbyjbrh.com/docs/email/approve-reject/)
- [Proof that a message was sent](https://connectbyjbrh.com/docs/email/send-evidence/)
- [The daily email allowance](https://connectbyjbrh.com/docs/email/daily-allowance/)
- [Regenerating a draft](https://connectbyjbrh.com/docs/email/regenerate-draft/)

## What this page is based on

- GENERAL.md §5 — autonomy modes, scopes and Needs You
- CHANNELS.md §1 — the shared send boundary and the allowance
- `backend/app/autonomy.py` — modes and scope order
- `backend/app/outbound.py` — the send boundary and its evidence
- `backend/app/metering.py` — the daily allowance