The primary mailbox
The primary mailbox is the one a workspace falls back to when nothing narrower has decided which address to use — a first message that is not a reply on an existing thread. It is expressed as a mailbox role rather than a flag on the workspace, so you change it by changing roles on the Mailboxes screen. A workspace with one connected mailbox has no ambiguity to resolve.
When a fallback is needed at all#
Most outgoing mail never consults a default. A reply belongs to a thread, the thread belongs to a mailbox, and that settles it. The fallback is reached only when there is no thread to inherit from: the first message of a new conversation, an outreach message, a follow-up that starts something rather than continues it.
- Does this message belong to an existing thread? If so, use that thread's mailbox and stop.
- Was a mailbox named by whatever asked for the message — a screen, a rule, an Assistant tool? If so, use it.
- Otherwise use the workspace's default sending mailbox.
That ordering is why changing which mailbox is primary is a quiet change on a busy workspace: everything already in flight keeps its own address, and the new default only shows up on things that start after it.
How the default is expressed#
There is no separate primary column on the workspace. The job the word describes is carried by the mailbox's role, which is also what decides the sending identity in the ordinary case. One place to look, one place to change, and no possibility of a workspace flag pointing at a mailbox that no longer exists.
Open
#/mailboxesand find the mailbox you want mail to originate from.Result Its row shows its role alongside its health and its autonomy.
Give it the role that makes it the workspace's default sender, and give the previous holder a different one.
Result Two mailboxes claiming the same fallback is the situation worth avoiding — not because it errors, but because which one wins stops being obvious from the screen.
Send one new message that is not a reply, and check the address it went out from.
Result That is the only proof that matters. The sent record carries the provider's own acknowledgement and names the mailbox it used.
A workspace that appears to have none#
There are three ways to arrive at a workspace where no mailbox can be the default, and they need different answers.
| What you see | What it actually is | What to do |
|---|---|---|
| No mailboxes at all on the screen | Either genuinely none connected, or a row stamped with an empty workspace_id | Add one — but first read the invisible-row case below, because reconnecting is the move that can make it worse |
| Mailboxes listed, none able to send | Health, not configuration: the connections read but cannot send, or credentials have lapsed | Mailbox health names the verdict; fix the connection rather than the role |
| A mailbox is listed and sending is refused | Autonomy or the daily allowance, neither of which is about the mailbox's identity | Held drafts covers the four holds and the order they are checked in |
The practical rule: if a workspace looks empty of mailboxes but you know one was connected, do not reconnect as the first move. Check whether by-id access to the mailbox still works — if it does, the row exists and the boot-time repair is what restores it to the list.
Deleting the default#
Disconnecting the mailbox that serves as the workspace's default does not cascade: conversations, contacts and history are canonical workspace records and remain. What stops is new mail arriving on that address and new mail leaving from it, which means anything that would have fallen back to it now has nowhere to fall back to until a role is given to another mailbox.
Set the replacement role before disconnecting rather than after. It costs one click in the right order and avoids a window where outbound work that starts a conversation has no identity to use.
Questions#
Does the primary mailbox receive mail addressed to the others?
No. Every connected mailbox is fetched on its own and its mail stays attached to it. Primary only matters in the outbound direction, for messages that do not already belong to a thread.
Can a customer workspace and the Owner set this differently?
Both set it the same way, on the same screen, through the same mailbox_console policy. There is no operator-only step here — the Owner connects and configures mailboxes exactly as a customer does.
What sends the first message of an outreach sequence?
The mailbox the outreach was raised against if one was named, otherwise the workspace default. Outreach and a customer reply are two paths with different gates — Outreach email versus a customer reply sets out where they diverge.