Build a call flow

Who this is for: buyers and networks whose routing needs more than an ordered list of targets — IVR input, branching, an external lookup, or a fallback path. What you’ll need: a working campaign, at least one target or RTB to route to, and the details of any integration the flow will call. Time: about 30 minutes for a first flow with one branch and one fallback.

A call flow is a reusable, node-based workflow for handling an inbound call. A flow can collect input, add tags, evaluate conditions, call an integration, route to a target or an RTB, invoke another call flow, or end the call.

Call flow or routing plan?

Both decide where a call goes. They are not ranked — they answer different questions.

Use a	When
Routing plan	The call should be offered to an ordered list of destinations and nothing else needs to happen first. This is the default execution mode and it is unchanged by anything here.
Call flow	Something has to happen before or between routing decisions — collect a digit, check a value, call an external service, branch on the answer, or fall back somewhere specific.

A campaign runs one or the other, set by its Execution Mode. Call flows are reusable, so the same flow can be selected by more than one campaign when the workflow suits each of them.

Before you begin

The campaign you will attach the flow to, and confirmation you are allowed to change its execution mode
The target, RTB, or RTB group the flow will route to, already open and available
For an integration node: the endpoint, method, headers, and the response shape the service returns
For any field the flow collects and reports on: the custom tag created ahead of time

The node types

flowchart TD
  A[Call arrives] --> B[Input / collection node<br/>digits, speech]
  B --> C[Tag node<br/>store the value]
  C --> D{Logic node<br/>branch on the value}
  D -->|matches| E[Integration node<br/>external lookup]
  D -->|blank or invalid| F[Fallback route]
  E --> G[Routing node<br/>Target, RTB, or another flow]
  G -->|no result| F
  G --> H[End node]

Node type	What it does	Watch out for
Input and collection	Gathers caller responses — keypad digits, speech, or other supported values	Always add a branch for blank, invalid, and unexpected input
Tag and logic	Stores values and branches on configured conditions	Tag names are not case-interchangeable. Use consistent lower-case names and verify the value actually exists at runtime
Integration	Exchanges data with a configured service	Use the portal-generated integration details. Never reconstruct a webhook URL from an example in a document
Routing	Sends the call to a target, an RTB, or another call flow	Which routing node types are available depends on your portal
End	Stops or hangs up the call	Give every branch an explicit ending — an unterminated branch is where calls go quiet

Step 1 — Create the flow

Open Call flows in the portal navigation (Data → Call flows) and create a new flow.
Name it for the job it does, not the campaign it currently serves — flows are reusable and the name outlives the first use.
Lay out the happy path first, end to end, with no branches: arrival → routing node → end.
Save.

Expected result: a saved flow with one complete path from arrival to an end node.

Step 2 — Collect and store caller input

Add the input node and define the expected response.
Store the response in a clearly named tag or field.
Add validation, plus a branch for blank, invalid, or unexpected input.
Use the persisted value downstream — in filters, routing, integrations, or reporting.

Keep tag names identical across collection, conditions, RTB requests, and reporting. A tag written as zip_code in the flow and read as ZIP_CODE in a condition will simply never match, and the branch will look like it was never taken.

Expected result: a test call that enters a value shows that value on the call record, and the condition branch you expect is the one that runs.

Step 3 — Add branching and failover

Failover in a call flow is explicit. There is no implicit “try the next thing” — you add the next route and connect the appropriate unsuccessful or no-result outcome to it.

An RTB route is evaluated using its actual configuration: endpoint or group placement, filters, request data, bid response, allocation, and downstream connection behaviour. Do not assume that an unsuccessful target or RTB automatically advances to another node. If you did not draw the edge, the call does not take it.

Expected result: every node with a failure or no-result outcome has that outcome connected to something — another route, a different flow, or an end node.

Step 4 — Add an integration node, if the flow needs one

Integration resources are managed from the relevant Integrations area, and the node references them. Copy the generated configuration out of the portal rather than assembling a URL by hand.

If the check needs to run after a buyer has been selected but before the call is bridged, that is a different mechanism — see Run a pre-bridge check before the call connects.

Expected result: the integration returns the response shape the flow expects, and the node’s outcomes are mapped to real branches.

Step 5 — Assign the flow to a campaign

Edit the campaign.
Set Execution Mode to call flow.
Select the flow.
Save.

Expected result: the campaign detail view shows the call flow as its execution mode. Until this is true, the flow is not in the call path.

Verify it works

Confirm the flow is assigned to the intended campaign and that the campaign is using call flow routing.
Test every branch: blank input, invalid input, no bid, failed route, timeout, and hangup paths that apply. Branches you did not test are branches you did not build.
Verify collected values persist and are available to downstream nodes.
Confirm integrations use the portal-generated configuration and return the response shape the flow expects.
Open Call Life on the test call and read the route the call actually took, not the one you intended.
Place one controlled live test before scaling traffic onto the flow.

Success looks like: a call log row for each branch you tested, and a Call Life timeline showing the nodes in the order you drew them.

Troubleshooting

Symptom	Likely cause	Fix
The flow never runs	The campaign is still on routing plan execution mode, or the flow was never assigned	Re-check step 5
A branch is never taken	Tag name mismatch, usually casing, or the value is not present at that point in the flow	Compare the tag name at collection against the one in the condition, character for character
Call goes silent partway	A branch has no connected outcome and no end node	Trace each outcome to an explicit next node
Integration node always fails	Hand-built URL, wrong method, or a response shape the node cannot read	Recopy the configuration from the portal, then compare the live response against what the node expects
A failed target does not fall over	Failover was assumed rather than drawn	Connect the unsuccessful outcome to the next route
RTB route behaves differently than expected	Its filters, group placement, or allocation behaviour, not the flow	How to troubleshoot RTB no-bid responses

Last reviewed: August 2026.