On callee answered

Fires when an outbound dial to an external party (not an internal agent) is answered. Use it for "play message on pickup" outbound campaigns or to log the…

What it does

Fires when a bridged leg picks up and the leg is not an internal extension — typically a dial to an external PSTN number, a partner answering service, or any third-party destination. The worker's bridge-leg handler tries to resolve the answering leg to a known internal extension first; when that lookup fails, it treats the leg as a "callee" and fires this trigger instead of onAgentAnswered. The two are mutually exclusive on a given bridge: exactly one of them fires per pickup.

While the chain runs, the worker stashes a small callee context on state.triggerCallee — including the bridge leg's call-control id — exposed to templates as {{callee.legCallControlId}} and {{callee.e164}}. As with the other answered triggers, the chain runs in an isolated state branch so it can't move the main flow's cursor; the bridge stays connected and audio flows normally throughout.

When to use it

• Play a "compliance announcement" to the caller (or both legs) the moment an external partner answers, before any conversation begins.
• Log the moment a third-party answered for a partner-routing analytics pipeline, separate from internal-agent answer events.
• Fire a webhook for outbound campaign auditing — "callee answered at HH:MM" with the destination number captured upstream.
• Branch on whether the dial resolved to an internal agent or an external callee by wiring different chains under each trigger type.

If the bridge target is one of your own extensions, use On agent answered — that fires for internal pickups and gives you full agent identity (agent.userId, agent.extensionNumber).

Configuration

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

Fires when an outbound dial to an external party (not an internal agent) is answered. Use it for "play message on pickup" outbound campaigns or to log the moment the recipient came on the line. Distinct from "On agent answered" — that fires for internal extensions; this fires for everything else.

Outgoing events: triggered

Examples

Play a recording disclosure when a partner answers

A side-chain that whispers a compliance message to the external party the moment they pick up, while the caller continues to hear silence on the bridge.

{
  "id": "callee-answered",
  "type": "onCalleeAnswered",
  "config": { "_label": "Disclosure to external party" },
  "on": { "triggered": "compliance-whisper" }
}

[onCalleeAnswered] ──► [say
                        prompt: "This call may be recorded.",
                        target: "agent"]
                   ──► [end]

target: "agent" reuses the bridge-leg targeting logic — with no internal agent identity in scope, the worker uses the first active bridge leg, which here is the external callee.

Gotchas

• state.triggerCallee is only set inside this chain. Templates like {{callee.e164}} and {{callee.legCallControlId}} only resolve while the chain is running. To use the callee number later in the call, copy it into vars here with a setVar. callee.e164 resolves to the dialed E.164 for legs originated by the dial node — the worker stamps the rendered destination into a bridgeLegToCallee map when it originates the leg, and looks it up here. If a callee leg fires this trigger but has no entry in that map (a future dial path we don't yet instrument, or a leg surfaced through some other origin), callee.e164 falls back to null and templates render empty — guard with {{#if callee.e164}} if you read the value defensively.
• Mutually exclusive with onAgentAnswered. Each bridge fires exactly one of the two. The router uses the bridge leg's extension-mapping table — if it finds an extension id, you get onAgentAnswered; if not, you get onCalleeAnswered. There's no way to fire both for one pickup.
• Agent-only nodes don't work here. Screen pop, Custom pop, and Agent toast all require state.triggerAgent, which is not set in an onCalleeAnswered chain. They log a warning and skip — use say / playAudio / httpCall / customScript for callee-answer side effects instead.
• Side-chain runs in an isolated state branch. Shares vars with the main flow but cannot move its cursor. The bridge stays connected while the chain runs; if your chain takes a long time (a slow httpCall), the conversation has already started and the chain catches up in the background.