On agent answered

Fires the moment the bridged agent leg picks up — distinct from "On call answered" which only marks the platform-↔-caller leg. This is the right trigger f…

type: onAgentAnswered status: stable sinceVersion: 0.1.0 seeAlso: [onCalleeAnswered, onCallAnswered, screenPop] keywords: ["onAgentAnswered", "agent", "answered", "screen pop", "whisper", "triggers"]

What it does

Fires the moment a bridged agent leg picks up — the internal extension that a dial or requestAgent node was ringing has accepted the call and audio is now flowing between the caller and the agent. This is distinct from On call answered, which fires on the caller-↔-platform leg at the very start of the call. By the time onAgentAnswered fires, you know exactly which user picked up: the worker resolves the bridged leg's extension to a user identity and stashes it on state.triggerAgent for the duration of the chain.

That makes this the only trigger where agent-targeted nodes can do their job. Screen pop (URL or Custom HTML), Agent toast, and whisper mode on say / playAudio all read state.triggerAgent to know whose softphone to push to — outside an onAgentAnswered chain, those nodes log a warning and skip. The chain runs in an isolated state branch after the worker publishes an agent.answered event to the agent's softphone, so any pops or notifications you fire arrive at the softphone with the right call context already in scope.

When to use it

• Push a CRM customer page to the agent's softphone with Screen pop (URL mode).
• Render an in-call HTML card (account summary, recent tickets) with Screen pop (Custom HTML mode).
• Surface a quick toast like "VIP customer — handle with care" via Agent toast.
• Whisper context to the agent without the caller hearing, using a say node with target: "agent".
• Stamp vars.answeringAgentId with {{agent.userId}} so an onCallEnd summary webhook can include who took the call.

Configuration

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

Fires the moment the bridged agent leg picks up — distinct from "On call answered" which only marks the platform-↔-caller leg. This is the right trigger for screen pops, custom HTML pops, agent toasts, and whisper messages: by the time it fires, you know who answered and can target their softphone.

Outgoing events: triggered

Examples

Pop a CRM page and whisper VIP context

A typical "screen pop + whisper" chain. The CRM URL templates the contact id resolved by an earlier contactLookup. The whisper plays only on the agent leg, so the caller hears nothing.

{
  "id": "agent-answered",
  "type": "onAgentAnswered",
  "config": { "_label": "VIP screen pop + whisper" },
  "on": { "triggered": "pop-crm" }
}

[onAgentAnswered] ──► [screenPop
                       url: "https://crm.acme.com/c/{{contact.id}}",
                       mode: "drawer"]
                  ──► [say
                       prompt: "VIP caller — be nice.",
                       target: "agent"]
                  ──► [end]

The agent's softphone receives the screen-pop event keyed by callId, so the URL opens in the right call drawer even if the agent has multiple calls in flight.

Gotchas

• state.triggerAgent is only set inside this chain. Templates like {{agent.userId}}, {{agent.extensionNumber}}, and {{agent.extensionId}} only resolve while the chain is running — the worker clears state.triggerAgent as soon as the chain finishes. If you need an agent identity later in the call, copy it into vars here with a setVar ({{agent.userId}} -> vars.answeringAgentId).
• Screen pop / Agent toast outside this chain do nothing. Those nodes check state.triggerAgent at runtime; if it's not set (the chain isn't an onAgentAnswered chain, or the bridged leg had no extension mapping), they log a warning and skip. Always wire them as descendants of an onAgentAnswered node.
• Only fires for bridged legs that map to a known internal extension. When dial connects to an external PSTN number — a partner agency, a third-party answering service — there is no extension and therefore no agent identity. The worker fires On callee answered instead. If you see your onAgentAnswered chain not running, check whether the bridge was internal or external.
• Side-chain runs in an isolated state branch. Shares vars with the main flow but cannot move its cursor. The agent's softphone receives the worker's own agent.answered realtime event before the chain runs, which is what lets pops fired by the chain land in the right per-call drawer.
• Auto-record fires after this chain. If your org has bridge-time auto-record configured, the recording starts after the chain completes — so a setVar here that flips vars._suppressAutoRecord = true will be honored, useful for opt-out compliance flows.