# Triage and priority

Triage sets `threads.priority` on the canonical thread, and the engine reads that column when it picks what to work on. Correcting a priority therefore changes behaviour rather than re-sorting a list. Starring and deleting are yours alone — they organise your view and the engine does not act on them.

- **Status:** Available
- **Audience:** both
- **Channels:** email
- **In the app:** #/inbox, #/needs-you
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/email/triage/

## Two kinds of mark, and the difference matters

| Mark | Column | Who reads it |
|---|---|---|
| Priority | `threads.priority` | You, the Conversations list, **and the engine when it picks work** |
| Starred | `threads.starred` | You. It is your flag on your view |
| Deleted | `threads.deleted_at` | You. The thread leaves your list; the record is not destroyed |

Every one of these lives on the canonical `threads` row rather than on the provider's copy, which is why they behave the same whether the mailbox is Gmail, Microsoft Graph or an IMAP server, and why they survive a mailbox being reconnected. The provider's own stars and labels are a separate world; moving state between the two is the write-back described on [Writing back to Gmail](/docs/email/gmail-writeback/).

The same three marks exist on `calls`, so a person's triage habits carry across channels without learning a second vocabulary.

## Why correcting a priority is not cosmetic

In most inboxes, priority is a sorting preference. Here it is an input. The engine reads `threads.priority` when it chooses what to think about, so raising a thread moves it up the queue of work that will actually get a draft written, and lowering one moves it down. A correction is a control action with a visible consequence, not a tidy-up.

That is also the honest reason to make the correction rather than complaining about the order. If a supplier's dispatch confirmations keep landing above a customer's complaint, the fix is at the thread, and it takes effect on the next pass.

> **Note** A correction changes what happens next; it is not, by itself, a lesson. If the mis-ranking will recur — this sender is always urgent, this newsletter never is — record it as a memory or a standing instruction so the next thread starts in the right place. [Making a correction actually change behaviour](/research/memory-correction-that-sticks/) is the longer argument.

## What triage does not decide

- **Whether a reply may be sent.** That is autonomy, resolved per channel and per scope, and a high priority does not raise permission.
- **Whether there is allowance left.** A high-priority thread refused by the daily allowance is still refused, and the refusal is visible in Needs You.
- **Whether the recipient may be contacted at all.** Suppression, unsubscribe and do-not-contact are checked before any outreach and outrank everything on this page.
- **What the reply says.** Priority orders the queue; grounding and memory decide the content.

Keeping those separate is deliberate. A single "importance" number that quietly also granted permission would be the kind of control nobody can reason about afterwards.

## Working the list

1. Open Conversations and read the top of the list rather than the whole of it.
   - Result: The ranking already reflects priority; the disagreements are what you are looking for.
2. Correct anything ranked wrongly, in either direction.
   - Result: The engine's next pass uses the new value.
3. Check Needs You separately.
   - Result: Held drafts, refusals and operational problems queue there, not in the conversation list. A quiet Conversations screen with a full Needs You is a normal, and busy, morning.

## Questions

### Does deleting a thread delete the customer's messages?

No. `threads.deleted_at` removes it from your working list; the canonical record and its history remain, which is what keeps a relationship timeline honest. It also does not delete anything at the provider — your Gmail or IMAP mailbox is untouched by that mark.

### Can Connect set a priority itself?

The column is read by the engine when it picks work, and a person's correction is the authoritative input this page documents. Treat the priority you set as the one that counts, and correct it whenever the ranking disagrees with you.

### Why is a thread I starred still low in the queue?

Because starring is your own flag and the engine does not read it. If you want the queue to move, change the priority — that is the column with consequences.

## Related

- [Conversation threads](https://connectbyjbrh.com/docs/email/threads/)
- [Giving guidance on a thread](https://connectbyjbrh.com/docs/email/guidance/)
- [Blocking a sender](https://connectbyjbrh.com/docs/email/blocking/)
- [What Connect may do](https://connectbyjbrh.com/docs/autonomy/)
- [Making a correction actually change behaviour](https://connectbyjbrh.com/research/memory-correction-that-sticks/)

## What this page is based on

- CHANNELS.md §1 — triage and blocking
- GENERAL.md §3 — a person's own triage on canonical rows
- `backend/app/triage_console.py`, `triage_api.py`
