> ## Documentation Index
> Fetch the complete documentation index at: https://dialnexa.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# DialNexa Statuses Reference
> Understand DialNexa statuses for call logs, batch calls, workflows, workflow leads, call transfers, phone numbers, integrations, webhooks, and call end reasons.
DialNexa statuses are lifecycle labels that tell you what happened, what is still running, and what you should check next. Use this DialNexa statuses reference when you review Call History, batch campaigns, workflow lead history, API responses, webhook payloads, transfer details, or exports.
Always read a status with the object it belongs to. `active` on a workflow, phone number, campaign, or integration does not mean the same thing.
## When To Use This Status Reference
Use this page when you need to:
* Explain a call, batch campaign, workflow, transfer, or integration state to an operator.
* Decide whether a status is final or still waiting for another update.
* Choose the right follow-up action, such as retry, resume, cancel, export, or inspect a call log.
* Map API or webhook values to dashboard behavior.
## DialNexa Statuses By Product Area
| Product area | Status field | What it describes | Primary place to review |
| ------------- | ------------------------------- | ----------------------------------------------------- | --------------------------------------------------------------- |
| Call logs | `status` | One phone or web call attempt. | [Call History](/monitoring/call-history) |
| Call logs | `end_reason` | The reason a completed, missed, or failed call ended. | [Call data model](/data/call-data-model) |
| Batch calls | `status` | One batch campaign container. | [Batch retries and statuses](/batch-calls/retries-and-statuses) |
| Workflow | `status` | The workflow container lifecycle. | [Workflow statuses](/workflows/workflow-statuses) |
| Workflow lead | `status` | One lead moving through a workflow. | [Lead history](/workflows/lead-history-and-debugging) |
| Call transfer | `status` | A warm transfer session or transfer leg. | [Call transfer](/calls/call-transfer) |
| Phone number | `status`, `rental_status` | Provisioning and rental state. | [Phone numbers](/calls/phone-numbers) |
| Integration | `status` | Connection or invocation state. | [Dashboard integrations](/dashboard-integrations/overview) |
| Webhook | Event status or delivery fields | Call event and delivery state. | [Webhook retries](/api-access/webhook-retries-and-failures) |
## Call Statuses
Call statuses describe one call attempt. They do not describe whether the business outcome was good. For example, `completed` means the call connected and ended, but you still need transcript, summary, post-call fields, sentiment, and `end_reason` to judge the result.
| Status | Final? | What it means | What to do next |
| --------------- | ------ | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| `created` | No | DialNexa created the call log and queued or prepared the attempt. | Wait for `initiated`, `sent`, or a final status. If it stays here, check queue and provider readiness. |
| `initiated` | No | Call setup has started. | Wait for provider updates. If it is stale, check route, balance, and call cleanup behavior. |
| `sent` | No | The outbound request was sent to the telephony provider. | Monitor for connection or final failure. |
| `received` | No | DialNexa received an inbound call or provider callback for the call path. | Wait for the next call event. |
| `completed` | Yes | The call connected and ended normally from the platform point of view. | Review transcript, recording, summary, fields, and `end_reason`. |
| `did_not_pick` | Yes | The recipient did not answer, voicemail was detected, or the call path classified the result as no pickup. | Retry if appropriate, or route the lead to a did-not-pick follow-up. |
| `busy` | Yes | The destination line was busy or rejected the attempt as busy. | Retry later or group it with unanswered recipients for follow-up. |
| `no_answer` | Yes | The provider returned a no-answer outcome. | Treat as an unanswered or failed attempt based on your campaign or workflow logic. |
| `failed` | Yes | DialNexa or the provider could not complete the call attempt. | Inspect `end_reason`, error details, route configuration, wallet balance, and destination validation. |
| `cancelled` | Yes | The call was cancelled before it completed, commonly when a campaign is cancelled and queued calls are stopped. | Confirm whether the parent campaign or workflow was cancelled intentionally. |
| `retry_expired` | Yes | Retry handling ended before the call reached a successful final result. | Review retry count, retry interval, and the previous attempts in the retry chain. |
### Call Status Groups
| Group | Statuses | Operational meaning |
| ------------------------- | ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------- |
| Waiting for call progress | `created`, `initiated`, `sent`, `received` | The call is not final yet. Do not export it as a final outcome unless you are investigating stuck calls. |
| Connected and ended | `completed` | The call reached a connected end state. Inspect conversation quality separately. |
| Recipient did not answer | `did_not_pick`, `busy`, `no_answer` | The recipient did not have a useful conversation. Use retry rules or follow-up campaigns. |
| Failed or stopped | `failed`, `cancelled`, `retry_expired` | The call path stopped without a successful conversation. Check route, balance, campaign control, or retry limits. |
## Call End Reasons
`status` tells you the call lifecycle state. `end_reason` gives the more specific reason behind a completed, missed, or failed outcome.
| End reason | Usually appears with | Meaning |
| ----------------------- | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| `user_disconnected` | `completed` | The caller or recipient ended the connected call. |
| `agent_disconnected` | `completed` | The agent side ended the connected call. |
| `user_did_not_pick_up` | `did_not_pick`, `no_answer` | The recipient did not answer. This includes provider no-answer, no user response, and timer-expired no-answer hangup causes. |
| `user_busy` | `busy`, `did_not_pick` | The recipient line was busy or the call was rejected as busy. |
| `user_unreachable` | `failed`, `did_not_pick` | The carrier reported that the recipient was temporarily unreachable. |
| `invalid_phone_number` | `failed` | The destination number was invalid. |
| `destination_forbidden` | `failed` | The route, country, carrier, or policy blocked the destination. |
| `network_failure` | `failed` | A network or carrier failure interrupted the call path. |
| `voicemail_detected` | `did_not_pick` | Voicemail was detected instead of a live recipient. |
| `system_failure` | `failed` | The platform could not complete setup after retry handling. |
| `system_at_capacity` | `failed` | Provider capacity or rate-limit handling was exhausted. |
| `insufficient_balance` | `failed` | Wallet balance was too low to start or continue the call. |
| `unknown` | Any final status | No more specific reason was available. |
## Batch Call Statuses
Batch call statuses describe the campaign container, not one recipient call. Recipient outcomes still use call statuses.
| Status | Final? | What it means | What to do next |
| ----------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| `draft` | No | The batch campaign is saved for review and is not ready to send calls. | Review file, number, schedule, retry settings, and dynamic variables before launch. |
| `active` | No | The campaign is ready or scheduled, but calls are not currently being processed. It can wait here before the start time or while another batch is running for the organization. | Confirm start time and readiness. Pause or cancel if it should not run. |
| `running` | No | DialNexa is preparing, sending, or monitoring calls for the campaign. | Monitor Call History, sent count, picked-up count, and retry behavior. |
| `paused` | No | The campaign is temporarily stopped. Already initiated calls can finish, but no new calls should be started until resume. | Resume when ready, or cancel if the campaign should stop permanently. |
| `completed` | Yes | All recipients reached final counted outcomes. | Export results, review failed and did-not-pick groups, and plan the next campaign. |
| `cancelled` | Yes | The campaign was stopped permanently. Queued calls are removed and related queued call logs can be marked `cancelled`. | Do not resume. Create a new campaign if you need to call the list again. |
| `initiated` | API acknowledgement | The legacy `/batch-calls` create response was accepted and a batch id was returned. It is not the long-running campaign status. | Fetch the campaign or call logs to track the real campaign lifecycle. |
### Batch Campaign Counters
| Counter | What it counts |
| ---------------------- | ------------------------------------------------------------------------ |
| `total_lead_count` | Total recipients loaded into the campaign. |
| `sent_lead_count` | Recipients for whom a call attempt was sent. |
| `picked_up_lead_count` | Recipients whose call connected. |
| `completed_leads` | Calls counted as completed. |
| `failed_leads` | Calls counted as failed, including failed, busy, and no-answer outcomes. |
| `did_not_pick_count` | Calls counted as did not pick. |
| `success_lead_count` | Completed recipient calls counted as successful for campaign reporting. |
## Workflow Statuses
Workflow statuses describe the automation container. They are separate from the statuses of leads and calls inside the workflow.
| Status | Final? | What it means | What to do next |
| ----------- | ------------------------ | --------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- |
| `draft` | No | The workflow is being built and should not process leads yet. | Add nodes, connect edges, upload leads if needed, and validate before activation. |
| `active` | No | The workflow can process leads. Existing leads without execution records can start when the workflow is activated. | Monitor lead history and call logs. |
| `paused` | No | The workflow is temporarily stopped. Leads already inside an active call step can finish, but new movement is paused. | Resume after investigation or cancel if it should not continue. |
| `completed` | Yes | The workflow is finished and should not continue processing leads. | Review results and duplicate if you need a new version. |
| `cancelled` | Yes | The workflow was permanently stopped. | Create or duplicate a workflow if you need another run. |
| `running` | Legacy active equivalent | Some older responses or UI controls may treat `running` like `active`. New workflow requests should use `active`. | Treat it as active when deciding whether pause controls apply. |
## Workflow Lead Statuses
Workflow lead status describes one lead execution, not the whole workflow.
| Status | Final? | What it means | What to do next |
| ----------- | ------ | -------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| `pending` | No | The lead exists, but no execution record has started yet. This can happen before activation or before the lead enters the graph. | Activate the workflow, confirm the lead file, and check graph validity. |
| `active` | No | The lead has an execution record and is currently at a workflow node. | Open lead history to see the current node and last transition. |
| `completed` | Yes | The lead reached a converted terminal path. | Review the path and linked call logs. |
| `dropped` | Yes | The lead reached a dropped terminal path. | Review why the lead moved to the dropped branch and whether follow-up is needed. |
### Workflow Voice Call Routing Statuses
Workflow Voice Call nodes route final call outcomes into output branches.
| Call status | Workflow branch | Meaning |
| ---------------------------------------------------------- | --------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| `created`, `initiated`, `received`, `connected`, `waiting` | No branch yet | The call is still in progress or waiting for a final update. |
| `completed` | `COMPLETED` | The call connected and ended. |
| `did_not_pick`, `busy` | `DNP` | The recipient did not complete a live conversation. |
| `failed`, `no_answer` | `FAILED` | The call failed or the provider reported no answer. |
| `cancelled`, `retry_expired` | Review required | These are final call statuses, but they are not default Voice Call node outputs. Inspect lead history if a lead stays at the call node. |
## Webhook And Runtime Call Events
These values can appear in call webhook handling or runtime event payloads. They are not always stored as the final call log `status`.
| Event or status | Meaning |
| -------------------- | ---------------------------------------------------------------- |
| `initiated` | Call setup started. |
| `connected` | The call connected to a live path. |
| `hangup` | A hangup event was received. |
| `completed` | The call completed. |
| `waiting` | The call is waiting for another runtime step or provider update. |
| `did_not_pick` | The recipient did not answer. |
| `busy` | The recipient line was busy. |
| `failed` | The call path failed. |
| `no_answer` | The provider returned no answer. |
| `recording_uploaded` | A recording was uploaded after the call. |
| `recording_ready` | A recording URL became available after a later provider update. |
| `received` | DialNexa received an inbound or provider event. |
| `recording_inbound` | An inbound recording event was received. |
## Warm Transfer Statuses
Warm transfer statuses describe whether a call transfer connected the customer to a human representative and what happened to each transfer leg.
| Transfer status | Meaning |
| ------------------------------------ | ------------------------------------------------------------------------------ |
| `transfer_connected` | The customer was successfully bridged to a representative. |
| `transfer_no_ic_answered` | No dialed representative answered within the hunt window. |
| `transfer_all_ics_busy` | Every representative line was busy. |
| `transfer_all_ics_rejected` | Every representative rejected the call. |
| `transfer_hunt_timeout` | The hunt window ended before any representative answered. |
| `transfer_briefing_failed` | The representative briefing could not be generated or played. |
| `transfer_bridge_failed` | The platform could not bridge the customer and representative. |
| `transfer_ic_dropped_during_handoff` | The representative disconnected during handoff. |
| `transfer_ic_silent_after_merge` | The representative joined but did not speak in the expected validation window. |
| `transfer_customer_disconnected` | The customer hung up during the transfer. |
| `transfer_system_error` | An internal transfer error interrupted the process. |
### Transfer Leg Statuses
| Leg status | Meaning |
| --------------------- | ----------------------------------------------------------- |
| `dialing` or `dialed` | The representative leg was dialed. |
| `ringing` | The representative line is ringing. |
| `answered` | A representative answered. |
| `winner` | This representative leg won the hunt and should be bridged. |
| `cancelled` | The leg was cancelled, often because another leg won. |
| `busy` | The representative line was busy. |
| `rejected` | The representative rejected the call. |
| `no_answer` | The representative did not answer. |
| `failed` | The representative leg failed. |
| `completed` | The representative leg completed. |
| `bridge_failed` | The leg answered but bridging failed. |
## Other Operational Statuses
| Object | Status | Meaning |
| ---------------------- | -------------------------------------------- | --------------------------------------------------------- |
| Phone number | `pending` | Provisioning or verification is not complete yet. |
| Phone number | `active` | The number is ready for supported routing. |
| Phone rental | `active` | Rental is current. |
| Phone rental | `expired` | Rental has ended. |
| Phone rental | `available_for_reassignment` | The number can be reassigned after expiry handling. |
| Call sentiment | `positive`, `neutral`, `negative`, `unknown` | Post-call sentiment labels used for filtering and review. |
| Integration connection | `pending` | Connection setup started but is not complete. |
| Integration connection | `connected` | The integration is connected and usable. |
| Integration connection | `error` | The connection hit an error and needs attention. |
| Integration connection | `disconnected` | The integration is no longer connected. |
| Integration invocation | `success` | The integration action completed successfully. |
| Integration invocation | `failed` | The integration action failed. |
## Status Debugging
`completed` only means the call connected and ended. Read the transcript, summary, recording, post-call fields, sentiment, and `end_reason` before judging the result.
Check the scheduled start time, whether another batch is already running for the organization, selected outbound number readiness, wallet balance, and destination validation.
Open lead history, check the current node, read the latest transition reason, and inspect the linked call log if the current or previous node is a Voice Call node.
Confirm the Voice Call node has an output configured for the final call group: `COMPLETED`, `DNP`, or `FAILED`.
Webhook delivery and call outcome are separate. Use webhook delivery logs to inspect response status, retry attempts, and receiver errors.
## Recap
* Call status describes one attempt. `end_reason` explains why it ended.
* Batch call status describes the campaign container. Recipient outcomes still use call statuses.
* Workflow status describes the automation. Lead status describes one lead inside it.
* Workflow Voice Call nodes route only final call outcome groups.
* Transfer statuses are separate from call statuses and describe handoff behavior.
## Related Reading
Filter and export call outcomes.
Review campaign lifecycle, retries, and recipient results.
Understand workflow and lead execution states.
See how call status and end reason fit into call records.