Voice Inbound Call

A call arrives. Before anyone picks up, there is a moment in which a workflow could look up the number, find the customer, check whether they have an open ticket, and decide what to do about it. This node is what happens at the end of that moment.

It is an action, not a trigger, and that is the whole design. The trigger tells you the phone is ringing; this node handles the call. Everything between them — a CRM lookup, a condition, a knowledge base search — runs while the caller is still hearing the ring tone. By the time an AI agent speaks, it can already know their name and what they bought.

Two of those five are required and one comes from the trigger. call_sid identifies the call and you fill it with a reference like {{voiceinboundtrigger_1.call_sid}} — it is how this node knows which ringing phone it is answering. Get it wrong and the node has nothing to act on.

Everything else follows from call_type. Set it to ai and you must name a Voice Agent node in ai_call_config; set it to human and you must give human_call_config a number to forward to. The panel hides whichever half does not apply.

The AI configuration has a variables map, and it is the reason this node is an action rather than part of the trigger. Whatever you put in it — a name from a CRM lookup, an account status, the last order — is available to the Voice Agent as it speaks.

That is the difference between “thanks for calling, can I take your name” and “hello Priya, is this about the order from Tuesday”. The lookup happened while the phone was ringing. Nothing about the agent is cleverer; it was simply handed the answer.

It runs from 1 to 60 minutes and defaults to 30. The default is deliberately generous, because the failure it exists to prevent is a workflow that waits forever on a call that ended badly. Set it a comfortable margin above your longest real call rather than tight.

Two other things belong to the Voice Agent and not here, which the node's own schema takes the trouble to say: recording the call, and the maximum length of the conversation. If you are looking for either in this panel, you are in the wrong node.

When this node runs it returns immediately with workflow_paused set and a reason of voice_call_wait, and the execution stops there. Nothing is running while the conversation happens. When the call ends the workflow resumes at this node, and only then does the output gain what the call produced.

That split matters when you are reading an execution. A run sitting on this node is not stuck; it is on the phone. A run that passed through it in a second either failed early or was never connected.

“Completed” does not mean “answered”. Every call ends, including the ones that rang out, hit a busy tone, or went to voicemail. Each of those resumes the workflow with a completed call and an empty transcript. The field that tells them apart lives inside the call record — the sub-status — and it names exactly which of those happened. Branch on it. A follow-up task that fires for “no answer” and for “had a ten-minute conversation” alike is worse than no follow-up.

A wrong call_sid fails quietly rather than loudly. It is a template, so a typo in the trigger's alias resolves to nothing rather than to an error, and the node has no call to attach to. When an inbound flow does nothing at all and the log looks clean, check this field first.

Human transfer is not the Transfer Call node. Setting call_type to human here decides who answers in the first place. Transfer Call — two lessons from now — moves a conversation that is already happening, usually because an AI agent decided it should. Both send a call to a person; only one of them interrupts something.