Changing plan, end to end
A plan change rewrites one record: the entitlement held against the workspace. It takes effect at the next piece of metered work rather than at a restart or a fresh sign-in, so what you notice first is usually a send that now goes through, or one that now does not. Runtime is untouched — a workspace sitting in Draft only stays in Draft only on any plan.
The flow, stage by stage#
- Trigger — a plan is agreed, a trial converts, or a plan is downgraded.
- User or external event — the commercial side of the change happens outside the workspace; verifying a customer payment is one of the two things that are deliberately the operator's alone.
- Authentication and workspace resolution — the entitlement is a control-plane record keyed to one workspace, so a change lands on exactly one and can never land on two.
- Ingest — nothing is fetched. A plan change touches no business data whatsoever.
- Canonical record — the entitlement row: the plan code, whether it is live, the daily numbers, the ceilings, and any signature the plan requires on outbound mail.
- Reasoning — none. The gate is arithmetic and state, not judgement.
- Knowledge, memory and rules — unchanged, and unchangeable by a plan. What Connect knows is the workspace's, whatever it is paying.
- Autonomy and approval — also unchanged. A plan decides what may be spent, never what may be done without asking.
- Action through a provider — the first metered work after the change reads the new row and is allowed or refused on it.
- Result — the new limits apply immediately; there is nothing to restart and nobody has to sign in again.
- Relationship, timeline and memory — untouched.
- Audit, usage and Needs You — today's usage rows keep the limit that applied when each was written, so the day's history stays truthful across the change.
What changes at once, and what does not#
| Thing | Effect | When |
|---|---|---|
| Daily counters | New numbers apply to the next reservation | Immediately |
| Resource ceilings | New ceilings apply to the next attempt to add | Immediately, on adding only |
| Live-for-sending state | Sending resumes or stops | At the next metered event |
| Required sending signature | Applied to outbound mail from that point | At the next send |
| Runtime mode | Nothing | Never — a person changes it, not a plan |
| Held drafts and follow-ups | Nothing is discarded or released | Never — approval is a human decision |
| Records, memory, knowledge, audit | Nothing | Never |
The usage already recorded for today is not rewritten. Each row stores the limit that was in force when it was written, so a plan raised at noon does not retroactively make the morning look generous — a small thing that matters whenever somebody reconstructs a day afterwards.
Downgrades, and the ceiling that is already exceeded#
A ceiling is checked when you add, not continuously. Lowering the number of mailboxes a workspace may hold below the number it already holds removes nothing: the connected mailboxes keep working, and the next attempt to connect another is refused with a message naming the number the plan allows and offering the two real options — remove one, or move up.
Daily counters behave the other way round, because a day is discrete. A lower number applies to the next reservation on the same day, which means a workspace can be over its new limit the instant the change lands, and simply stops until midnight UTC. Nothing already sent is undone.
Checking that it landed#
- Look at the account view: the plan code and whether the workspace is live for sending are the two fields that decide everything else.
- Compare today's usage rows against the new numbers — a row written before the change carries the older limit, which is correct rather than stale.
- Try the thing that was refused. The refusal message names the reason, so a change that has not taken effect is distinguishable from one that has by reading a sentence.
- If a plan requires a current pass alongside the subscription, check that too: an expired pass refuses in exactly the same shape as an inactive plan, and is fixed differently.
Questions#
Do I need to sign out and back in after a plan change?
No. The gate reads the entitlement at the moment work is reserved, not at sign-in, so the change is live for the next send or sync. If a screen still shows the old numbers, that is a stale view; the enforcement has already moved.
If I downgrade, do I lose mailboxes?
No. A ceiling is enforced when adding. Existing connections keep working and the next attempt to add one is refused with a message that says how many the plan allows. Removing one is your decision, not something the change makes for you.
Does upgrading release work that was held?
It releases work held by an allowance, because the next reservation now succeeds. It releases nothing held by an autonomy rule, because that is a human decision and no commercial change is allowed to answer it.