Friday, 4:47 pm: an automation is sending confirmations for the wrong branch. Calling the developer is not an operating model. A prepared team has a better answer: a known switch, a named owner and somewhere safe for new work to land.
A kill switch need not take down the entire application. It should stop the risky capability: sending messages, writing appointments or changing records. Reading and logging may continue if that helps the team recover.
Use three controls, not one dramatic red button
| Control | What stops? | What continues? |
|---|---|---|
| Pause | New automated actions | Open cases remain visible |
| Safe mode | Writing, sending and deletion | The team works manually |
| Rollback | Faulty release or configuration | Last verified version returns |
Decisions to make before the incident
- Who may stop the workflow outside office hours?
- Which job, token or action is actually paused?
- Where do new requests wait during the pause?
- Which completed actions need reconciliation?
- What five checks permit a restart?
The common failure is a switch without an operating procedure. If nobody knows whether leads disappear or customers will be processed twice, people hesitate to use it. Run a harmless drill: pause the workflow, submit a test request, verify the manual queue and resume under supervision.
Rollback includes more than code
Prompts, permissions, routing rules and knowledge sources are versions too. After a bad change, the team must know exactly which set was active. The incident-response template covers communication, while an agent inventory identifies affected systems.
A small workflow does not need a control room. A documented pause control, a manual inbox and one rehearsed restart are usually enough. Build them while everything is calm.
Sources
FAQ
Does every automation need a kill switch?
Read-only assistants may need only a simple off control. Workflows that send, book, delete or change data should allow the risky action to be paused separately.
Who should be allowed to stop it?
At least one business owner and one technical owner should know the procedure, with the permission itself tightly controlled.
Does rollback delete data?
A good rollback restores code or configuration. Business actions already completed are reconciled separately rather than blindly reversed.
How often should it be tested?
After material changes and on a recurring schedule proportionate to the workflow's impact.