Turning Connect on and off
The runtime control stops Connect working. Nothing is triaged, drafted, sent or dialled while it is off, and the engine is not deciding anything to refuse. It changes no setting: your autonomy rules, held items, memory, commitments and plan are exactly as you left them, and switching it back on resumes work rather than replaying it.
What stopping actually stops#
- Work. Triage, grounding, drafting, deciding — the loop that turns an arriving message into a prepared action.
- Output. Nothing is sent on any channel and no call is placed, whatever each channel's mode says.
- New entries wanting a person. Nothing new is queued for approval, because nothing is being prepared to queue.
It does not stop the outside world. People keep writing and keep ringing; commitments keep falling due; the day the plan counts against keeps passing. A stopped runtime is a statement about Connect's own activity, and the work not done while it is off is waiting when it comes back.
Four things it does not change#
| Not changed | Why it matters |
|---|---|
| Autonomy modes and every exception | An autonomous channel is still autonomous when you switch back on. Stopping is not a way to reset a configuration you regret |
| Items already held | A decision waiting for a yes is still waiting. Approving one while the runtime is off is a decision recorded against a send that has to wait |
| Memory, knowledge and directions | Nothing is forgotten, and a block on a contact is not lifted by a stopped engine |
| The plan and its ledger | The commercial arrangement is a separate control entirely — see Entitlement against runtime |
When stopping is the right move#
- Something is visibly wrong and you need a moment
- A mis-set rule, a wrong knowledge source, a mailbox connected to the wrong account. Stop, fix the cause, start.
- A migration is in progress
- Moving mailboxes or numbers between providers. Better than half-configured credentials producing refusals nobody can interpret.
- A business closure
- A shutdown period where replying at all would be wrong. Note that held items are still held when you return, and some will be stale.
- An investigation
- Freezing activity while the decision log is read, so the picture does not move while you read it.
For anything narrower than the whole workspace, prefer the narrower tool. One noisy channel is a channel-level mode change; one difficult account is a contact-level exception. The runtime control is deliberately blunt, and its bluntness is the reason it is easy to reason about.
Coming back#
Switch the runtime on.
Result Work resumes from the current state of the world, not from a recording of what happened while it was off.
Read Needs You first.
Result Operational problems that developed during the stop — a mailbox whose credentials lapsed, a line that degraded — are ranked above the decisions underneath them.
Check anything held from before the stop for staleness.
Result A reply prepared last week may answer a message the customer has already followed up; regenerate rather than release it.
Check any phone commitments that fell due during the stop.
Result A call-back more than a day late is closed as missed rather than made, so some of them will need a person to ring instead.
Questions#
Does turning Connect off stop mail arriving?
It stops Connect acting. Customers keep writing and keep calling whatever the switch says — the difference is that nothing is being prepared, decided or sent in response while it is off.
Is this the same as setting every channel to off?
The effect on output is similar; the meaning is not. Channel modes are configuration you keep, and they survive a restart. The runtime control is a temporary stop that changes no rule at all.
Nothing is happening and I did not stop anything — where do I look?
Check the runtime control first, then Needs You for an operational fault, then whether a capacity limit has been reached. Those three account for nearly every quiet workspace; Nothing is happening works through them in order.