RoutingrequestAgentstable

Request agent

Rings one or more of your team's extensions in the background and immediately continues the flow. Place a Say or Play node next to give callers a hold exp…

What it does

Rings one or more of your team's extensions in the background and immediately continues the flow to the next node. The flow you put next to it controls what the caller hears while they wait (Say "please hold", a looping Play Audio, an IVR Gather "press 1 for voicemail", etc.). When an agent picks up, the caller is bridged in — interrupting whatever node they were on. If the flow chain finishes before any agent answers, the call follows the chain's own terminal: voicemail, hangup, transfer to a fallback flow, whatever you wired.

This shape is intentional. The node doesn't decide what hold music to play, doesn't have a "no answer" branch, doesn't park the call in a silent room while it waits. All of that belongs to the rest of your flow — Request agent just kicks off the rings and gets out of the way.

Each selected extension rings on its own ring order and ring time — the timeline configured on the extension itself (its devices, in the order and for the duration set there). This node has no ring-strategy or timeout field of its own; it just says who to ring.

When to use it

  • Ring a small, named set of people and start a hold-music loop next to it — when someone picks up, they're auto-bridged with the caller
  • Route a phone number to "an extension" via the phones page binding — set extensionIdsFromBinding: true so the target id is read from the phone's config.extensionId instead of being hardcoded
  • Pick the target dynamically from a Custom script: write the resolved id into vars.targetExtensionId, then put "{{vars.targetExtensionId}}" in the extensionIds list. Templated entries are rendered before the originate fanout
  • Give this caller priority over another queue or direct ring competing for the same agent, with priority

For a team that shares incoming calls with a waiting line, announcements, or an overflow destination, use Send to queue with a queue whose strategy is ring_group instead — it covers the same "ring everyone, first answer wins" shape plus the settings this node doesn't have (max wait, then-go-to, hold music).

Configuration

Rings one or more of your team's extensions in the background and immediately continues the flow. Place a Say or Play node next to give callers a hold experience while agents ring (e.g. "please hold" + looping music). Every chosen extension rings on its own ring order, for this node's Ring time when set, otherwise for the extension's own ring time. The extension's greeting and voicemail never apply here: this flow decides what happens when nobody answers. When an agent answers, the caller is bridged in — interrupting whatever node was playing. If the flow's chain finishes before any agent answers, the call follows the flow's terminal (voicemail, hangup, etc.). For a team that shares calls, use Send to queue with a ring-group queue instead.

FieldLabelTypeRequiredDefaultNotes
extensionIdsWhich extensions to ringextensionsRequired[]Inactive extensions are skipped.
extensionIdsFromBindingUse the extension from the phone bindingbooleanOptionalfalseAdvanced. When checked, the target extension is read from the phone's binding (config.extensionId) and merged with the list above. Only set this on flows backing the phones-page "Routes to → an extension" mode — leave off for normal ring nodes.
timeoutSecsRing time (seconds)numberOptional0How long the extensions ring before the ring stops. Match it to the hold node after this one so the flow moves on as the phones stop. Leave blank to use each extension's own ring time.
priorityPrioritynumberOptional0Higher wins when this caller and another (a queue or another direct ring) compete for the same agent. Ties break by who has waited longest. Leave blank for normal priority (0).

Outgoing events: next

Example: ring two agents, play hold music, fall to voicemail

The Say + Play Audio chain plays to the caller while both extensions ring. Whichever device picks up first (on whichever extension's own ring order finishes first) is bridged in. If neither answers before the music chain ends, the flow lands on Record and takes a voicemail.

[onFlowStart]
   ↓
[answer]
   ↓
[say "Thanks for calling — connecting you now."]
   ↓
[requestAgent extensionIds=[alice, bob]]   ← fire-and-forget
   ↓
[playAudio sys:music/default-hold]
   ↓
[record voicemail]
   ↓
[hangup]

The corresponding JSON for the Request agent node:

{
  "id": "ring-team",
  "type": "requestAgent",
  "config": {
    "extensionIds": ["ext-alice-uuid", "ext-bob-uuid"]
  },
  "on": { "next": "play-hold-music" }
}

Gotchas

  • Single outgoing edge (next). There's no no.answer / failed / call.bridged branch on this node — wire the chain's own terminal (voicemail, hangup, another node) to handle the no-agent case.
  • Hold music belongs to the flow, not the extension or the node. Put a Play Audio (or Play music) node after Request agent to control what callers hear while it rings.
  • The agent's answer interrupts whatever the caller is on. If Request agent is followed by a Gather Digits and an agent picks up while the caller is mid-press, the gather is cancelled and the bridge happens immediately. onAgentAnswered fires at the same moment, so whispers / screen pops / CRM logging still run.
  • The flow's terminal cancels still-ringing agents. If the chain reaches a Hangup or finishes a Record node before any agent answers, all in-flight rings are cancelled. Agents see their phone stop ringing.
  • No strategy or timeout field on this node. Each extension's own ring order and ring time (set on the extension) controls how long and in what order its devices ring — there's nothing here to tune per-flow. If you need a shared ring window, a priority order across a team, or an overflow destination, use Send to queue with a ring_group queue.

See also