This document describes the Voiceflow node and its usage within workflows. It covers supported entities, Voiceflow selection, conversation handling, node configuration, retry and call-drop behavior, and the use of ABT events and metadata to build workflow paths based on voice call outcomes.
Voiceflow
Voiceflow nodes can be accessed through workflows. This is required to initiate calls from a workflow. Currently, voice node supports the following entities:
- Candidate
- Applicant
- Job (only if Candidate match is used)
Once a Voice node is added, the user is immediately prompted to select a Voiceflow. These Voiceflows are pre-configured for the agency. Only the Voiceflows which are configured for the entity on which the workflow is created are available for selection.
For Candidate Match use cases, the entity on which the workflow is created is Job. To add a Voiceflow, use a for-each node to get all Voiceflows for a Candidate.
Voice conversation
A Voiceflow node is designed to handle the complete conversation, which can include multiple calls. A conversation can consist of original calls, rescheduled calls, incoming calls, or retries initiated by the system.
Each specific job for which a candidate is contacted is treated as a separate conversation. If a candidate is contacted for multiple jobs, each job is considered a separate conversation.
The conversation flow is managed within the Voiceflow node using the configuration provided in the workflow.
Voiceflow node configuration in Workflow
Once a Voiceflow is selected for the node, the following three sections must be configured:
- List of variables which are used in voiceflow needs to be mapped to a specific variable in the ATS
- Call Retries config
- Settings
Variable Mapping
The list of variables used in the Voiceflow must be mapped to the specific variables in the ATS.
If the agency has Entity Attribute Designation mapping configured, the variables will appear locked in the agency settings. If this is not configured, users must add the relevant variables so they can be resolved during the call.
Retries and Retry Reminders
Retries can be configured through the Voiceflow node call retries configuration. Users can configure retries within the Voice node.
- Retries support configuration in days or hours
- The minimum interval supported is 1 hour
Any retry that falls within blackout settings is automatically queued to run after the blackout setting ends.
The maximum aggregate retry duration must be less than the number of days configured in the agency setting voice_incoming_call_lookup_in_days. To allow longer retry durations, this configuration must be updated in the agency settings.
Handling call drops
Call drops are handled within the voice node.
If a candidate provides consent to talk and the call drops midway, the voice agent automatically calls back to complete the call. This callback occurs even if retries are not configured in the Voiceflow node. The callback is initiated after 4 hours.
Once the candidate answers, the call resumes from the point of disconnection. A candidate can also call the voice agent number at any time to complete the discussion.
Using ABT and metadata information in Workflow
A Voice conversation can result in multiple outcomes, which are handled intrinsically by the Voiceflow node. The relevant outcome is passed to the screened candidate dashboard.
The following scenarios describe the possible outcomes for a voice call:
| Scenario | ABT event | Metadata filter |
| Either the person did not respond or disconnected | Call Attempted | No response |
| the call has gone to a voice message | Call Attempted | Voicemail reached |
| Call disconnected because the number is not in use or incorrect | Call Attempted | Number not correct |
| Respondent picked up the call and disconnected without speaking | Call Attempted | No response but picked up |
| A person has answered the call but did not identify with the name stated and prompted to disconnect | Call Completed | Identification not successful |
| We tried calling but the number was not correct. | Call Completed | Number incorrect |
| The person was successfully identified but they declined to talk about the opportunity. Additionally they asked not be contacted again in future | Call Completed | Consent revoked |
| Person was successfully identified but they declined to talk about the opportunity | Call Completed | Opportunity mismatch |
| The person answered all the questions. | Call Completed | Ready for evaluation |
| The person answered the questions but midway was determined not to be a good fit and therefore, other questions were not relevant to be asked. | Call Completed | Evaluation not needed |
| The call was mark completed because the retries max limit was reached | Call Completed | Max retries reached |
| The call was mark completed because post call drop, script was not completed | Call Completed | Abrupt termination |
Building paths using the metadata filter
Users can create several rules to execute in the workflow by adding ABT(Action Based triggers) and metadata filters in the workflow.
Example Use Cases
- Send reminder message if the original call is missed: Use “Call attempted” ABT event with “no response” metadata filter to create a path. An SMS node can be added to the path so that the reminder is sent.
- If the voiceflow is configured to send voicemail messages then the metadata filter will take the value “voicemail reached” instead of “no response”.
- Here only the first call is supported for building the workflow and additional retries are not supported.
- Run additional automation if all three missed calls are not picked: Use “Call completed” ABT event with “Max retries reached" as a path variable
Best practices for choosing the time frame for Voiceflow node for which the conditions needs to be checked and move ahead:
- For ABT event Call Attempted, configure the time frame to be at least 1 day and no longer than the value set in
voice_incoming_call_lookup_in_days. - For ABT event Call Completed, configure the time frame to be at least the value set in
voice_incoming_call_lookup_in_days.
Adding Scenarios in the Workflow Post Call Completion
There are two possible scenarios when using the Voiceflow node:
- If steps need to be executed immediately after the call is queued, without waiting for the conversation or call outcome, do not use Voice ABT event–based paths.
- If steps need to be executed after the conversation is completed and depend on the call outcome, use Voice ABT event–based paths.
Note: This document applies to the Voiceflow node released on 22nd Dec, 2025 only. This does not apply to the legacy Voiceflow node.