Dial number

What it does

Originates an outbound call leg to a single destination — either a phone number in E.164 form or a sip: URI — and bridges it to the caller as soon as the destination picks up. Unlike Transfer, the platform stays on the call after the bridge: recording can start automatically, and when the conversation ends the call ends. Logic for afterwards (log it to a CRM) goes under After the call ends.

While we're waiting for the destination to ring, you can play optional ringback or hold music from the Prompts & music library to the caller (ringback; blank = the standard ringback). The bridged audio replaces that playback the moment the leg connects. If the destination doesn't answer within timeoutSecs or is busy, the flow follows No answer (no.answer). If the call can't be placed at all (an empty or refused destination, a dial-policy block, a failed leg), it follows Failed (failed). Each falls back to the other when only one is wired, so wiring just one to voicemail covers both.

When to use it

• Forward an inbound number to an external answering service or on-call cell phone with a voicemail fallback when no one picks up
• Reach a single SIP endpoint (a desk phone in a remote office, a paging speaker, a third-party IVR) — paste the sip: URI directly
• Loop in a supervisor by name with a custom caller-ID display so they see the original caller's number, not yours
• Build "warm transfer" flows where you need to keep control after the bridge — e.g. record the conversation, run an agent-whisper, or end the call programmatically. Use Transfer instead if you just want to hand off and walk away
• Implement a try-this-number-first fallback before falling through to Request agent

Configuration

Calls out to a single phone number or SIP address and connects them with the caller. When they hang up the call ends. If the destination doesn't answer (or is busy) the flow continues on "No answer"; if the call can't be placed at all (refused, unreachable, blocked by your dialing rules) it continues on "Failed" — each falls back to the other when only one is wired, so you can send both to voicemail.

Outgoing events: no.answer, failed

Examples

Forward to an external number, fall back to voicemail

The classic "ring my cell, take a message if I miss it" pattern. The dial node is the body of the flow; the No answer edge is the safety net.

{
  "id": "ring-cell",
  "type": "dial",
  "config": {
    "to": "+15555550199",
    "from": "{{event.to}}",
    "timeoutSecs": 30,
    "ringback": "sys:music/default-hold"
  },
  "on": { "no.answer": "voicemail" }
}

Reach a SIP endpoint with custom caller-ID name

Pass through the inbound caller's number as the caller-ID so the desk phone's screen shows who's actually calling, not the platform DID.

{
  "id": "reception",
  "type": "dial",
  "config": {
    "to": "sip:reception@office.acme.com",
    "from": "{{event.from}}",
    "fromDisplayName": "External Caller",
    "timeoutSecs": 20
  },
  "on": { "no.answer": "voicemail" }
}

Gotchas

• There is no "connected" edge. The platform reports a dial when its leg ENDS, so an answered dial simply ends the call once the conversation is over. Older flows' call.bridged edges never ran and are dropped on save; old call.hangup edges become No answer.
• Originate failures take Failed. If the platform rejects the originate (bad SIP URI, blocked country, no trunk capacity) or your dialing rules refuse it, no leg gets created and the flow follows Failed (or No answer when Failed isn't wired).
• ringback is a library reference, never a URL. It holds asset:<uuid>, sys:<kind>/<slug> (e.g. sys:tone/us-ringback) or a {{…}} template that renders to one. A raw URL fails publish validation.
• The leg counts as a "callee", not an "agent". Because there's no extension binding for a raw to number, the bridge doesn't resolve to an internal user — onAgentAnswered-only nodes (screen pop, agent toast, whisper) won't fire for it. Reserve those for bridges through requestAgent or an internal transfer.
• Templating renders once, at originate time. {{vars.x}} in to, from, or fromDisplayName is resolved when the dial node is entered. Mutating those vars later has no effect on a leg that's already ringing.