> ## Documentation Index
> Fetch the complete documentation index at: https://docs.firetone.com.au/llms.txt
> Use this file to discover all available pages before exploring further.

# Modules

> The optional parts of FireTone, the two switches in series that decide whether one runs, and what switching one off actually stops.

**Settings → Modules** lists the optional parts of FireTone and switches them
off across the whole install.

| Module               | What it is                                                                                                  |
| -------------------- | ----------------------------------------------------------------------------------------------------------- |
| **AI agent**         | answers calls as a virtual agent, live assist, the knowledge base, *Try it* and the Virtual agent flow step |
| **Tickets**          | the tickets screen, and an agent or an IVR step raising one during a call                                   |
| **Outbound calling** | outbound routing rules and service levels, voice broadcasting and the automatic dialler                     |

<Warning>
  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.
</Warning>

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.

| Fact                  | Fixed by                                |
| --------------------- | --------------------------------------- |
| **Not in this build** | a deploy. The code is not in the binary |
| **Switched off**      | this checkbox                           |

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.

<Note>
  **Absent means on.** Only modules explicitly switched off are recorded, so
  a module added in a later release is on the moment it ships.
</Note>

## 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.

<Warning>
  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.
</Warning>

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.