Call Flows
Call Flows let you build reusable, node-based workflows for handling inbound calls. A flow can collect input, add tags, evaluate conditions, call integrations, route to a Target or RTB, invoke another Call Flow, or end the call.
Open Call flows from the main portal navigation to create and manage flows. Integration resources used by a flow are managed from the relevant Integrations area.
How campaigns use Call Flows
A campaign can be configured to execute a Call Flow as its routing method. Call Flows are reusable, so the same flow can be selected by more than one campaign when the workflow is appropriate for each campaign.
Always confirm the campaign's selected routing mode before testing. A saved Call Flow does not affect traffic until it is assigned to an active campaign and that campaign is configured to execute it.
Build the flow node by node
Input and collection nodes gather caller responses such as keypad digits, speech, or other supported values.
Tag and logic nodes store values and branch based on configured conditions. Use consistent lower-case tag names and verify that the value is actually present at runtime.
Integration nodes exchange data with configured services. Use portal-generated integration details; never reconstruct a webhook URL from an example.
Routing nodes can send the call to a Target, an RTB, or another Call Flow, depending on the node types available in your portal.
End nodes can stop or hang up the call when the workflow requires it.
Collecting IVR responses
Add the appropriate input node and define the expected response.
Store the response in a clearly named tag or field.
Add validation and a branch for blank, invalid, or unexpected input.
Use the persisted value in downstream filters, routing, integrations, or reporting.
Keep tag names consistent across collection, conditions, RTB requests, and reporting. Do not assume casing is interchangeable.
Branching and failover
Call Flows can branch to another configured route when a prior route does not succeed. Failover is explicit: add the next route and connect the appropriate unsuccessful or no-result outcome to it.
An RTB route is evaluated using its actual configuration, including endpoint or group placement, filters, request data, bid response, allocation, and downstream connection behavior. Do not assume that every unsuccessful Target or RTB automatically advances to another node.
Testing checklist
Confirm the flow is assigned to the intended campaign and the campaign is using Call Flow routing.
Test every branch, including blank input, invalid input, no bid, failed route, timeout, and hangup paths that apply.
Verify collected values persist as expected and are available to downstream nodes.
Confirm integrations use the portal-generated configuration and return the response shape expected by the flow.
Review Call Life and reporting for the actual route taken, then place a controlled live test before scaling traffic.