Stopping Connect, end to end
The runtime switch stops Connect picking up new work, and changes nothing else. Every autonomy mode, mailbox, line and standing instruction stays exactly as it was, so switching back on resumes the configuration you already had. What has already been handed to a provider is beyond recall: the switch governs what happens next, not what has happened.
The chain#
- Trigger — a person uses the runtime switch, in the app header, because something needs to stop now.
- User or external event — the switch is the event; no customer, provider or timer is involved.
- Authentication and workspace resolution — the change applies to one workspace, the caller's, and cannot reach another.
- Ingest — inbound mail, messages and calls are unaffected by design: what arrives still arrives and is still recorded.
- Canonical record — the runtime state is stored as workspace state, separately from every autonomy setting.
- Reasoning — the engine stops selecting work on the next tick. Nothing part-way through a decision is abandoned mid-write.
- Knowledge, memory and rules — untouched. This is not a configuration change and leaves nothing to restore.
- Autonomy and approval — modes are not altered. An
autonomouschannel is stillautonomous; it simply has no work being picked up. - Action through a provider — anything already accepted by a mailbox, a messaging provider or the carrier has left; the switch cannot recall it.
- Result — new outbound work stops. Held items stay held; nothing in the queue is discarded.
- Relationship, timeline and memory — nothing is rewritten. The timeline shows the gap as an absence of activity, which is what happened.
- Audit, usage and Needs You — the switch is recorded like any other decision, so 'why was there no activity on Tuesday' has an answer.
Stage by stage#
| Stage | What you see | What changes | What can fail |
|---|---|---|---|
| Switching off | The state in the app header, on every screen | One piece of workspace state | Expecting it to apply to a colleague's workspace; it is scoped to yours alone |
| Inbound | Mail, messages and calls still arriving | Conversations keep being recorded | Assuming inbound stops too — it does not, and that is deliberate: a stopped agent should not also be a lost record |
| In flight | Anything already sent staying sent | Nothing | Using the switch to stop a message that has already gone; the send boundary hands work to a provider and does not take it back |
| The queue | Held items unchanged | Nothing | Reading a still-full Needs You as a fault; the switch stops work being created, not work being decided |
| Switching on | Activity resuming from the next tick | The engine picks up what is due | Being surprised by a burst: follow-ups that came due while it was off are due now |
| The log | The decision recorded with who made it | The decision log | Nothing — the entry is written either way |
When this is the right control#
- Something is going out that should not
- This is the fastest blunt stop. Diagnose afterwards; the decision log still holds everything that happened before you used it.
- A migration or a mailbox move
- Stopping the engine keeps it from acting on half-migrated data, without you having to remember what every channel was set to.
- A quiet period you want to be genuinely quiet
- A holiday closure where nothing should be answered automatically, and where changing modes would risk restoring them wrongly afterwards.
- A permanent narrowing
- Not this. If a channel should never send on its own again, change its autonomy mode — the switch is for now, not for policy.
The distinction is worth keeping: the switch answers *stop*, and autonomy answers *what is allowed*. Using one to express the other is how a workspace ends up switched off for a month because somebody meant to disable one mailbox.
Coming back on#
Look at Needs You before you switch on.
Result Anything that was held is still held, and deciding it first avoids a burst of activity landing on top of a queue you have not read.
Check the follow-ups screen for dates that passed while it was off.
Result A phone follow-up more than 24 hours late is closed as missed rather than rung, so a long stop leaves visible gaps rather than a sudden wave of stale calls.
Switch on, then watch the decision log rather than the outbox.
Result The log shows what the engine picked up and what it refused, which is the faster read of whether the resumption behaved.
Questions#
Does switching off lose anything that arrives while it is off?
No. Inbound mail, messages and calls are still fetched, recorded and attached to the right person. What stops is Connect acting on them. When you switch back on, the material is there and the engine works through it.
Can I stop only one channel?
Yes, but not with this control — set that channel's autonomy mode to off instead. The switch is deliberately whole-workspace, because its job is to be the one thing you can use without thinking about scope.
Who can switch it?
A member with permission over the workspace's runtime state. The change is recorded with the person who made it, so a workspace that was quiet for a day can say why rather than being investigated as a fault.