Skip to main content
Settings → Modules lists the optional parts of FireTone and switches them off across the whole install.
Switching Outbound calling off does not merely remove the campaign screens. Without its rules, an organisation dialling through your carriers has no route at all and every outgoing call is refused. Only a tenant that owns a trunk keeps dialling. That is most tenants affected.
Dialling itself is core, so a number forwarding to a mobile is unaffected.

​
Two switches, in series

They are not interchangeable, and the screen shows them as two facts because they are fixed in two different ways. A switch here can only narrow what the build carries. It can never add a module back, because there is nothing to add — which is why a module that is not built has no switch at all, and the row says what would actually help instead. Every optional module is listed even when this binary does not carry it. Absent from the list is indistinguishable from “there is no such module”, and an operator looking for why tickets have gone would find nothing at all.
Absent means on. Only modules explicitly switched off are recorded, so a module added in a later release is on the moment it ships.

​
What switching one off actually stops

Four layers, and stopping at the first would be worse than having no switch.
  1. The menu entries disappear.
  2. The settings tab and the panels it contributes to other screens disappear, rather than being drawn and failing.
  3. Its API routes answer 403 module_disabled. A bookmark, a typed URL or an API key cannot reach a module you turned off.
  4. The call path refuses it. A published flow with a virtual agent step, a campaign already running and a handset dialling an extension all reach the call path without going anywhere near the panel. If the switch stopped at the browser, the settings screen would read AI: off while AI answered the next call.
The switch is checked when a call arrives, not when the daemon starts, so one thrown at three in the afternoon is honoured by the call that arrives at three in the afternoon.

​
Where the line is drawn

It stops a module taking on new work. It does not abandon work already in flight, and two things are left running on purpose:
  • A call the module already started is still recognised by it. Refusing to recognise it would not prevent any work — the call would fall through and could be sent straight back out to a carrier, so the operator pays to ring a stranger.
  • Billing for calls it took still settles. Switching a module off must not be a way to get free minutes out of the calls it already answered.
Switching one off asks you to confirm; switching one back on does not, because the worst case there is a feature working again.

​
Removing a module’s data

Switching a module off removes nothing. Data removal is a separate and deliberately harder second step, and the panel for it appears only while the module is off. That ordering is the point. Removing the data of a module still answering calls would delete rows out from under work in progress, and requiring the switch first means a reversible decision was made before an irreversible one.
This is the most destructive thing in the product. It asks for three separate things: the operator permission, the module already switched off, and the module’s own name typed in. Each answers a different way of getting here by accident — the wrong person, the wrong moment, the wrong module.
It removes everything that module has stored, for every organisation on this server, and it cannot be undone. Billing records are kept: charges and price lists are settled facts. That is said out loud because the opposite is the natural assumption, and getting it wrong either way is somebody’s money. Only a module that is still present can be pruned, so the order is switch off, remove the data, then take it out of the build. Cleaning up after a module that has already gone is not something the product can offer, and the screen says so rather than showing a dead control.