On call transferred

Fires when the call is handed off to another destination (transfer or bridge to an extension). Reads the destination as vars.transferTo so chains can log…

What it does

Fires when the caller leg bridges to a destination — either an internal extension via requestAgent, an external number via dial, or any other handoff that produces a call.bridged event on the parent leg. The worker captures the destination identifier into vars.transferTo before running the trigger chain, so your downstream nodes can read where the call is going via {{vars.transferTo}} templates.

Use this trigger to log handoffs, ping a CRM with the destination, or branch on transfer target. The chain runs as a side-chain in an isolated state branch — the main flow stays parked on the bridge so the caller's audio path is unaffected.

When to use it

• POST a "transferred to {{vars.transferTo}}" event to your CRM so reps can see the handoff trail in the customer record.
• Send a Slack ping with the destination number/extension when a call is bridged to a partner organization.
• Use a customScript to look up the transfer target in your own database and stash the agent's display name in vars for later use.
• Increment a per-extension transfer counter for your routing analytics.

If you want to act on a specific agent picking up the bridge — for screen pops, custom HTML, agent toasts — use On agent answered instead. onCallTransfer fires on the bridge moment; onAgentAnswered fires on the agent leg pickup, which carries agent identity.

Configuration

_label and _note are author-only metadata; this trigger has no runtime configuration of its own.

Fires when the call is handed off to another destination (transfer or bridge to an extension). Reads the destination as vars.transferTo so chains can log to a CRM, ping Slack, or branch on the target.

Outgoing events: triggered

Examples

Log every transfer to a CRM

A side-chain that fires whenever the call bridges, posting the destination to a webhook.

{
  "id": "transfer-trigger",
  "type": "onCallTransfer",
  "config": { "_label": "Log transfer to CRM" },
  "on": { "triggered": "post-transfer" }
}

[onCallTransfer] ──► [httpCall POST /api/crm/transfer
                       body: {
                         from: "{{event.from}}",
                         to: "{{vars.transferTo}}"
                       }] ──► [end]

The main flow's bridge node runs in parallel:

[answer] ──► [requestAgent ext=200] ──► (call.bridged → onCallTransfer fires) ──► [end]

Gotchas

• vars.transferTo is the destination string from the bridge event. For dial-to-PSTN it's an E.164 number; for requestAgent it's the internal SIP target. The worker pulls it from the to field of the call.bridged payload (or from client_state.to as a fallback). If the bridge event lacks a destination, vars.transferTo is left untouched — templates may render an empty string.
• Fires on every bridge, not just human-to-human transfers. Any call.bridged event on the parent leg triggers this — including the initial connect to an answering agent on a routine inbound call. If you only want to fire on re-routes after an agent already answered, combine with vars.transferTo checks or branch logic in the chain.
• Side-chain runs in an isolated state branch. Cannot move the main flow's cursor, but shares vars. The main flow's bridge handling continues independently — your chain will not delay the bridge from completing.
• onAgentAnswered and onCalleeAnswered may fire on the bridge leg shortly after. Those triggers run from the bridge-leg call.answered handler, which is a separate event from the parent-leg call.bridged that fires this one. Order is not guaranteed — design your chains to be independent.