phone_number.hotline_id,
a nullable foreign key to a row in dim_hotline. Nothing else on the call
path reads it.
What a hotline bucket is
A hotline bucket is a row in thedim_hotline dimension table, scoped to
one org. The Phone numbers screen reads four of its columns:
The picker renders each option as
code · name, so a bucket with code
SUPPORT-EU and name EU support line appears as
SUPPORT-EU · EU support line.
The query behind the field is, in effect:
code drives the sort order, codes with a common prefix
(SALES-…, SUPPORT-…) group together in the dropdown.
Creating and deactivating hotline codes
The Phone numbers screen does not create, rename, or deactivate hotline codes. It is a consumer ofdim_hotline only — it lists the active rows
and lets you bind one to a number. Codes are maintained outside this
screen, and the drawer will not offer a bucket that does not already
exist for the org.
Two consequences follow from the active = true filter:
- A newly added code appears as soon as it is active. Reopen the drawer (or reload the screen) to refresh the list; the hotline list is fetched with the numbers and trunks when the screen loads.
- Deactivating a code hides it from the picker but does not unbind
numbers. Rows that already carry that
hotline_idkeep it. The drawer for such a number has no matching active option to display, so re-saving the number through the drawer can drop the stale binding. Move numbers to a replacement bucket before a code is deactivated.
Binding numbers to a hotline
Pick a bucket in Reporting hotline and save. The field is clearable — the empty state is— None —, which stores hotline_id: null.
The save goes through the admin API’s phone-number upsert:
status, not on
hotline_id; changing only the hotline binding does not re-deploy or
undeploy the number.
The drawer’s Deactivate and Reactivate actions pass the existing
hotline_id through unchanged. Deactivating a number is a soft delete —
status becomes inactive, the BFF pulls the Redis DID index so inbound
INVITEs stop resolving, and the row (with its hotline binding) is
retained. Reactivating restores routing with the same bucket still
attached.
e164 is immutable once a number exists; the hotline binding, trunk, and
agent ID are all editable on an existing number.
Where hotline roll-ups appear in reports
The binding is a stored dimension key, not a computed field. Reporting readsphone_number.hotline_id and joins dim_hotline for the code
and name labels. Because the key lives on the number and not on the
call, it applies from the moment it is saved — rebinding a number to a
different bucket changes how that number’s subsequent traffic rolls up
and does not retroactively relabel anything already attributed to the
previous bucket.
If a number has hotline_id: null, its traffic carries no hotline
dimension and rolls up only under the org, trunk, and agent dimensions
that the number already has.
Hotline vs VDN: reporting against routing
These are easy to confuse because both look like “a code attached to a number”. They sit on opposite sides of the call.
The drawer’s hint says it plainly: reports only — no routing effect.
Changing a hotline never changes who answers.
The destination fields this screen offers are:
- Trunk — inbound termination, where matched calls land. Optional;
the empty state is
— unassigned —. - Agent ID — optional direct routing to an AI agent, entered as a
free-text
agent_xxxidentifier.
vdn_id destination. If you are
following provisioning material that describes routing a DID to a VDN,
that destination is not settable from the Phone numbers drawer, and the
Reporting hotline field is not a substitute for it — a hotline has no
routing behaviour at all. Set the trunk (and optionally the agent) here
for termination, and use the hotline purely as the reporting label.