Recording, and what is kept

The one rule that decides whether a call is recorded, where the audio lives, and how long anything is kept.

FireTone can record a call, take a voicemail and keep a transcript of what an AI agent said. Three different stores, three different answers to “how long”, and one rule deciding whether a call is recorded at all.

Whether a call is recorded

Six settings can switch recording on, and the call is recorded if any of them says so. They are not a hierarchy and none overrides another:

Level	Where it is set	Covers
Organisation	Organisations → the tenant	every call the tenant makes or takes
Team	Teams & agents → the team	calls handled by anyone on that team
Extension	Extensions → the extension	calls that desk makes or takes
Queue	Queues → the queue	calls offered through that queue
Trunk	Trunks → the carrier	calls carried over that carrier
Process	Processes → the service	calls that arrived through that service

A switch can turn recording on and cannot turn it off. Switching “record calls” off on an extension does not stop recording if the organisation, the team, the queue it came through or the carrier it came over has it on. To stop recording a call, switch it off at every level that covers it.

The call’s own page names which level did it, so “why was this recorded” has an answer without opening six screens. On a call that was not recorded, the same line reads no level of this call has recording enabled.

The one way it can fail quietly

A node needs somewhere to put the file. If recording is on and the node has no recordings directory configured, nothing is recorded and the panel looks exactly as it does when recording is off. The daemon says so at warning level and the call’s page carries enabled, but this node has no recordings directory. An operator fixes it by setting FIRETONE_RECORDINGS_DIR on that node.

Where the audio lives

A recording starts as a file on the node that took the call, named after the call. Where it goes next depends on whether the organisation has given FireTone a bucket of its own:

• With cloud storage configured, the file is handed to the organisation’s own bucket. It is then reachable from any node, survives a node being rebuilt, and sits on storage the organisation controls — which also means they can apply their own lifecycle rules to it if they would rather answer the retention question themselves.
• Without it, the file stays on the node that took the call. That works, and it has three limits worth knowing: one disk, unreachable from other nodes, and gone if that node is rebuilt.

Either way the panel plays it from the same button, and a recording is only ever played by somebody holding recordings:listen.

How long anything is kept

Three windows, set per organisation, because these are three different exposures with different answers. A recorded sales call and a member of the public’s voicemail are not the same risk.

What	Setting	Default
Call recordings	Recording retention	none — kept indefinitely
Voicemail	Voicemail retention	none — kept indefinitely
AI transcripts	Transcript retention	365 days

Nothing is deleted unless somebody asked. Recording and voicemail windows are empty until a number is typed, and empty means keep. This is deliberate: software that starts destroying a tenant’s recordings because an upgrade invented a default is worse than software that keeps too much. The transcript window is the exception — it has carried 365 days since the store was created, and that is a default, not a recommendation. A tenant with a shorter obligation should lower it.

Set all three under Organisations → the tenant. Each accepts 1 to 3,650 days.

What deletion actually does

A sweep runs every hour and takes a bite at a time rather than one long delete, so a busy system is not locked while it runs.

The file and the row go together. A recording of somebody’s voice that nothing points at any more is the worst kind of file to leave on a disk, and a row pointing at a file that has gone is a broken player in the panel. So each is removed with the other — and where audio has moved to an organisation’s bucket, the row is cleared only once the object is gone. If the bucket cannot be reached, the row stays, on purpose: an orphaned recording is exactly what this is meant to prevent.

Deleting a recording does not delete the call. The call record, its duration, its cost and its outcome stay; what goes is the audio and the transcript.

Who can hear what

Reading and listening are different permissions, and they are different disclosures:

Permission	Lets somebody
recordings:listen	play a call recording, or a conference session’s
voicemail:listen	play a voicemail message
voicemail:read	see that a message exists, and read its transcription
conversations:read	read what was said on an AI call, as text

A person with conversations:read and no recordings:listen can read a transcript and cannot hear the voice. That is the intended shape: the text answers “what was agreed”, the audio is the recording of a person.

Telling callers

FireTone records what you tell it to record; announcing it is yours to do, and in most places it is the law. An IVR flow can play an announcement before anything else happens, which is the usual place for it. Nothing in the product announces recording on your behalf.