# Send certain mail to a person instead

There is no separate routing table for mail. You get the behaviour by narrowing autonomy at the scope that matches the exception — one contact, one mailbox, one channel or the whole workspace — so the reply is held for a person instead of sent. For work that is not a reply at all, a follow-up on the `task` channel is the mechanism: no drain ever sends one, so it can only be completed by somebody.

- **Status:** Available
- **Audience:** both
- **Channels:** email
- **In the app:** #/autonomy, #/needs-you, #/follow-ups, #/inbox
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/how-to/route-mail-to-a-person/

## Pick the scope, not the feature

The question to answer first is how wide the exception really is, because that maps directly onto the four autonomy scopes. They resolve narrowest first, so a rule on one contact overrides the mailbox's, which overrides the channel's, which overrides the workspace's.

| The exception | Scope | Set it to |
|---|---|---|
| This one client's mail always needs a human eye | Contact | `ask_before_send` |
| Everything to the accounts address is checked | Endpoint (one mailbox) | `ask_before_send` |
| Nothing on this channel goes out unread, for now | Channel | `ask_before_send` |
| We want to watch what it would say without saying it | Any scope | `draft_only` |
| This channel should not be used at all | Channel | `off` |

> **Note** `draft_only` and `ask_before_send` are easy to confuse and behave very differently. `ask_before_send` puts the reply in front of a person and waits. `draft_only` writes it and stops, on purpose, without queuing anything for approval — which is what you want while evaluating, and not what you want if somebody is supposed to act.

## Setting one up

1. Open the screen for what Connect may do and find the scope you decided on. For a single person, set the rule against that contact rather than against the channel.
   - Result: Every other conversation carries on unchanged. This is the difference between an exception and a policy change.
2. Set the mode. For "a person must see this before it goes", that is `ask_before_send`.
   - Result: Replies on that scope are written and held rather than sent.
3. Say why, in the same sitting, as guidance on the thread or as a memory row at the matching tier.
   - Result: The person who inherits the queue in three months knows the rule is deliberate. A held reply with no explanation gets released by somebody who assumes it was an accident.
4. Wait for the next real message on that scope and open Needs You.
   - Result: The held draft is there with the message it answers above it. That is the verification: the rule is proved by an item appearing, not by the settings screen agreeing with itself.

## When the work is not a reply

Some mail should not produce a reply at all — it should produce a job. A follow-up carries a channel, and one of the channels is `task`, meaning work for a person. No drain ever sends a `task` follow-up; it appears under work for a person to do and stays there until somebody completes it. That is the honest way to route something to a colleague, because it is visible, dated, and carries a reason.

A follow-up without a reason is not useful to whoever inherits it, and a follow-up with the same due time for the same person is treated as a duplicate rather than added twice. Both of those rules exist because the queue is only trusted while it is accurate.

Priority is the third lever and the least obvious one. A conversation's priority is read by the engine when it picks work, so correcting a priority changes what gets attention rather than just re-sorting a list for your eyes.

## What an exception looks like from the outside

To the customer, nothing. A held reply has not been handed to any provider, so there is no message in flight and no delivery attempt: it is not a slow reply, it is no reply, and whatever clock the customer is counting is still running. That is the cost of the exception and the reason to make it as narrow as the problem.

**Nothing appears in the queue** — The mode is probably `draft_only`, which deliberately does not ask anyone. It writes and stops.
**Items appear for conversations you did not mean to include** — The rule was set at a wider scope than intended — the channel rather than the contact.
**The exception stopped applying** — A narrower rule was added later and is winning. The decision log names the rule each action was taken under, which resolves this faster than reading settings screens.
**The colleague never sees it** — Approval needs permission to send on that channel. A `task` follow-up, by contrast, is visible to anybody working the queue.

## Questions

### Can I route by subject line or by keyword?

Not as a rule of its own. Routing here is by who the correspondent is, which mailbox the mail arrived at, and which channel it came on. A keyword rule that quietly stops matching is a worse outcome than an explicit contact-scope rule that keeps applying.

### Does holding a reply tell the sender anything?

No. Nothing has been sent, so there is no read receipt, no delivery attempt and nothing in the sent folder. The sender sees silence, which is why held work needs somebody actually working the queue.

### What is the difference between this and blocking someone?

Routing sends the decision to a person; blocking removes the correspondence entirely, across every channel, and holds for future conversations too. Use a block when the answer is permanently no, and a narrow autonomy rule when the answer is "a human decides".

## Related

- [What Connect may do](https://connectbyjbrh.com/docs/autonomy/)
- [Needs You](https://connectbyjbrh.com/docs/autonomy/needs-you/)
- [Follow-ups in Connect](https://connectbyjbrh.com/docs/follow-ups/)
- [Triage and priority](https://connectbyjbrh.com/docs/email/triage/)
- [Give one customer special treatment](https://connectbyjbrh.com/docs/how-to/handle-a-vip/)
- [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 modes and scopes
- docs-source/sources/CHANNELS.md §7 — follow-up channels, reasons and duplicates
- docs-source/sources/GENERAL.md §3 — `threads.priority` and the engine
- docs-source/sources/CHANNELS.md §1 — the send boundary