On call answered

Fires the moment the platform confirms the caller is connected (the conversation has actually started). Drop this anywhere on the canvas as a side-chain t…

What it does

Fires the moment the carrier confirms the caller leg is live — the inbound call has been picked up by the platform and audio is now flowing on the parent leg. This is the first lifecycle event after the call is answered and before any IVR audio plays. The trigger runs as a side-chain, so attaching nodes here is purely additive — your main flow continues from wherever it was (typically the answer node) without waiting for the trigger chain to finish.

A common pattern is a thin chain that posts to a CRM, marks the call as "answered" in your own database, or starts a wall-clock metric that you'll later read in onCallEnd. Because every node in the chain runs in an isolated state branch, the side-chain can't accidentally hijack the call — even if its httpCall stalls or errors, the main flow keeps moving.

When to use it

• Post a "call answered" event to a CRM or analytics endpoint with the caller's number and your phone number.
• Stamp vars.answeredAt with {{event.from}}-context state for later use in an onCallEnd summary webhook.
• Send a Slack ping to an #inbound channel when a call is picked up.
• Kick off a httpCall that fetches contact details from a CRM, even earlier than contactLookup — the result is available to the main flow through vars.

If you only care about the moment a human agent picks up (after a dial / requestAgent bridges), use On agent answered instead — that fires on the agent leg and gives you agent.userId / agent.extensionNumber for screen pops.

Configuration

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

Fires the moment the platform confirms the caller is connected (the conversation has actually started). Drop this anywhere on the canvas as a side-chain to log the answer time, ping a CRM, or kick off background work — the main flow keeps running independently.

Outgoing events: triggered

Examples

Post a "call answered" webhook

A minimal side-chain that fires a single HTTP POST when the caller connects, then ends without affecting the main flow.

{
  "id": "answered-trigger",
  "type": "onCallAnswered",
  "config": { "_label": "Notify CRM on answer" },
  "on": { "triggered": "post-crm" }
}

[onCallAnswered] ──► [httpCall POST /api/crm/answered] ──► [end]

The main flow runs in parallel:

[onFlowStart] ──► [answer] ──► [say "Thanks for calling..."] ──► [menu] ──► ...

Gotchas

• Fires only on the parent (caller) leg. Bridge legs that pick up later do not re-fire onCallAnswered. If you need the agent-pickup event, wire On agent answered; for an outbound dial answered by an external number, wire On callee answered.
• Side-chain runs in an isolated state branch. The worker snapshots state.currentNodeId and restores it after the chain finishes, so the trigger can't move the main flow. It still shares the same vars object, so a setVar here is visible to the main flow — useful, but a footgun if you race against it.
• Auto-record can fire right after this trigger. Orgs configured with from_answer recording timing start the carrier-side record immediately after onCallAnswered runs. If your trigger sets vars._suppressAutoRecord to true, the auto-record is skipped — handy for compliance flows that want to play a consent prompt first.
• Doesn't fire on ext-to-flow originated calls in the obvious way. When a flow is started by an outbound originate (the call was already picked up by the user's softphone before the flow began), the start state has alreadyAnswered: true. The platform may still emit a call.answered event afterward, which fires this trigger — but the timing is shifted compared to a normal inbound. Don't assume "first audio in" semantics here for those flows.