Mailbox roles
A role is a stored value on the mailbox row that says what the address is for. It is the thing that later decides which mailbox a reply is sent from, and it gives the engine the standing context that a message arrived at a sales address rather than a support one. It is set on the mailbox and changed there; nothing else in the workspace has to be reconfigured when it changes.
What a role is for#
A workspace with one mailbox has nothing to disambiguate. One with three does, because two questions have to be answerable without a person present: which address a reply goes out from, and what kind of correspondence this is before anybody has read it.
- The sending identity
- A reply is sent from the mailbox the thread belongs to. That is settled by what the mailbox is for, together with the thread's own history — it is not chosen per message, and it is not editable at the moment of approval.
- Standing context for drafting
- A message that arrived at an address whose role says *support* is being answered by something that already knows it is a support message. That is context the model does not have to infer from the body.
- A natural scope for settings
- Autonomy, signature and memory all resolve at the mailbox — the *endpoint* tier. This field is what makes a per-mailbox rule legible six months later, when 'the ask-first one' has stopped being a description anyone remembers.
The value is stored on the row, not derived from the address. Two mailboxes on the same domain can differ, and renaming the underlying address at your provider does not change what Connect thinks the mailbox is for.
What changes when you change one#
| Thing | Effect | Why |
|---|---|---|
| Existing threads | Stay on their mailbox | A thread is already attached to the mailbox it arrived on; changing it does not re-route history |
| Drafts already written | Unchanged | A held draft is a finished text; regenerating is what picks up new context |
| Drafts written afterwards | Written with the new standing context | It is read when the draft is built, not cached |
| Autonomy on that mailbox | Unchanged | Autonomy is its own field on the same row and is not implied by it |
| The signature | Unchanged | Also its own field — see Mailbox signatures |
| Health verdicts | Unchanged | Health is derived from what the connection actually did, not from configuration |
The change is therefore safe to make on a live workspace, and it is worth making rather than working around. The common workaround — leaving every mailbox at the default and encoding the difference in a standing instruction instead — puts the distinction somewhere that only affects wording, not routing.
Choosing one#
Ask what a stranger writing to this address is most likely to want.
Result That answer is usually the role. An address that receives three unrelated kinds of correspondence is a sign that it should be more than one mailbox, not that it needs a cleverer role.
Check whether the address should ever originate a message, or only reply.
Result A monitored alias that must never start a conversation is a different case from a working address, and getting this wrong is the mistake that shows up publicly.
Set the autonomy that matches, on the same row.
Result Role and autonomy are independent fields, and the pairing you want — a support address answering on its own, a finance one that always asks — is two settings, not one.
What a role does not do#
A role is not a permission. It does not decide whether Connect may send, whether an allowance applies, or whether a recipient is contactable — those are autonomy, metering and compliance respectively, and each is checked independently of what the mailbox is called.
It is also not a filter. Mail arriving at a mailbox is not discarded because it does not match the role; a sales enquiry sent to a support address is still triaged, still answered, and still attached to the same person. The role shapes the answer rather than gating the work.
Questions#
Can two mailboxes hold the same role?
Yes, and it is normal — two regional addresses doing the same job, for instance. Where it matters is fallback: if more than one mailbox could serve as the workspace's default sender, make the distinction with the value you give the one you want chosen rather than relying on order.
Does the role appear to the recipient?
Not by itself. What a recipient sees is the address the message came from and the signature attached to it. This field is internal — it decides which address that is, and it informs how the reply is written.
I changed a role and a reply still went out from the old address.
That is expected on an existing thread. Threads keep the mailbox they arrived on, so the change applies to what happens next rather than to correspondence already under way.