Configuring a phone line
A line is configured by ten facts on one channel_routes row, and each one refuses something specific: assignment decides whose line it is, the two permissions decide direction, hours decide when, routing decides which workspace and behaviour, the recording policy and capabilities decide what the provider will allow, limits decide what may be spent, and status decides whether any of it runs.
The fields, and what each one is for#
provider- Which adapter speaks to the carrier. It also fixes which capabilities are askable at all — a provider that carries no SMS answers no to SMS however the line is configured.
assignment- Whose line this is: the business's own public line, a line kept for one purpose, or one person's browser endpoint. Assignment is what the softphone match on the caller's
Fromcompares against. - inbound permission
- Whether a call arriving on this number is answered. Off here is not the same as the line being switched off; see Switching the line off.
- outbound permission
- Whether Connect, a follow-up drain or a person may originate a call from this number. Checked by
may_place_callbefore any dial. - hours
- The open window, in the line's own timezone, used both for refusing a call and for turning a promise like "tomorrow morning" into a real due time.
- routing
- Which workspace owns the number, and which behaviour a call on it belongs to. This is read first, before any other setting.
- recording policy
- What would be recorded if the provider permitted it. On the live carrier nothing is, because recording is
foundation. - capabilities
- The provider's own answers about recording, transfer and WebRTC, cached so that nothing above the adapter has to guess.
- limits
- Per-line ceilings — how long a call may run, what it may cost — enforced by admission and metering rather than by hope.
- status
- On, off, or unhealthy. An unhealthy line is a Needs You item that drains by itself when its cause clears.
Deciding them in the right order#
Three of these depend on the others, so a line configured out of order produces settings that look right and do nothing.
Set routing first: which workspace owns this number.
Result Every later read happens inside that workspace, which is where the credentials, hours and behaviour live.
Set the provider and let the capabilities be filled in from it.
Result The recording and transfer controls now show what this carrier will actually do, rather than what the model can store.
Set the two permissions, then hours.
Result Hours only ever narrow a permission. A line with inbound permission off is closed at every hour of the day, and its hours change nothing.
Set limits and the voice behaviour last.
Result These change how a call goes, not whether it happens, so a mistake here is a bad call rather than no call.
What a wrong setting looks like from outside#
| What is reported | Usual cause | Where to look |
|---|---|---|
| "It rings and rings" | Inbound permission off, or no worker has checked in | The line's permission, then Capacity and admission control |
| "It answered and said goodbye" | Hours closed, or the line switched off | Hours in the line's timezone — not yours |
| "Nothing appears in Connect" | The number is not claimed by this workspace | Routing, then the carrier's own call log |
| "Connect never calls anyone back" | Outbound permission off on the line the follow-up would use | may_place_call and the follow-up's channel |
| "Calls stop after a few minutes" | A per-line limit, or the product ceiling of 30 minutes | Limits, then Session limits and long calls |
Changing a line while it is in use#
Configuration is read per call, not cached for the life of a process, so a change takes effect on the next call rather than at the next restart. A call already in progress keeps the settings it started with — including the voice profile, which is snapshotted onto the call's quality record precisely so that a later review judges what actually ran rather than what the screen says today.
The one change that is felt immediately by a caller is status. Switching a line off does not cut the calls on it; it stops the next one being answered as a conversation and gives it the spoken closed-line message instead.
Questions#
Can two lines in the same workspace behave completely differently?
Yes. Each line is its own row, so hours, permissions, limits and voice profile are per line. A profile pinned to one line number beats the workspace default without changing anything else, which is the usual way to give a service number a different manner from a sales number.
Why can I set a recording policy that does nothing?
Because the policy is a workspace's stated intent and the capability is the provider's answer, and they are deliberately separate values. Keeping the intent recorded means the line does not have to be reconfigured if it is ever moved to a carrier that supports recording — but until telephony.can() says yes, nothing is recorded and no page should suggest otherwise.
Does turning inbound permission off stop outbound calls too?
No, they are independent. A line can be outbound-only — never answering, only calling — which is a reasonable configuration for follow-up call-backs from a number you do not want published.