> ## Documentation Index
> Fetch the complete documentation index at: https://docs.open.cx/llms.txt
> Use this file to discover all available pages before exploring further.

# Phone call lifecycle and outcomes

> Understand call status, outcome, and disposition; use call completion events without assuming a connected call reached a person or has a final summary.

A phone attempt has a connection lifecycle and a result. Keep these separate from the session's resolved or unresolved status: a connected call does not prove the customer's request was resolved.

<Note>
  Disposition-based follow-ups require **Call → Disposition** in your workflow builder. If it is absent in your workspace, contact support before configuring these recipes. Existing **Outcome** values alone cannot distinguish busy, declined, and voicemail.
</Note>

## Status, outcome, and disposition

| Field            | What it describes                                            | Examples                                                                                          |
| ---------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------- |
| Call status      | The attempt's connection state                               | Initiating, ringing, in progress, completed, missed, no answer, busy, rejected, failed, canceled. |
| Workflow outcome | The broad way an AI call ended                               | `completed`, `transferred`, `unanswered`, `failed`.                                               |
| Disposition      | The more specific result supported by available evidence     | `busy`, `voicemail`, `human_answered`, or `unknown`.                                              |
| Session status   | Whether the customer session remains open or has been closed | Independent of whether a person answered the phone.                                               |

## Disposition reference

| Disposition      | Meaning                                                                          |
| ---------------- | -------------------------------------------------------------------------------- |
| `human_answered` | Answer detection identified a person on a connected call.                        |
| `no_answer`      | The attempt ended without an answer.                                             |
| `busy`           | The call result explicitly reported a busy line.                                 |
| `declined`       | The call was rejected; the result does not necessarily identify who rejected it. |
| `voicemail`      | An answering-machine greeting was detected.                                      |
| `failed`         | The attempt failed.                                                              |
| `canceled`       | The attempt was canceled.                                                        |
| `unknown`        | There is insufficient evidence to identify the answer type.                      |

Busy, declined, canceled, and voicemail attempts use the broad workflow outcome `unanswered`. A connected call can have `completed` with disposition `unknown`. Keep an explicit fallback branch instead of treating every unclassified call as answered by a person.

For outbound AI calls with answer detection, the agent listens before its greeting. When voicemail is detected, it ends the call without leaving a message. Detection can be inconclusive: test the languages and routes you use. In sequences, detected voicemail is a failed voice step with reason `voicemail`, and does not count as a reply that exits the journey.

## Use Call Finished

The **Call Finished** trigger supports follow-ups after AI calls, including outbound attempts that fail before the agent speaks. It is separate from **Make phone call**, which initiates a call; that action's success output is not evidence of a human answer.

| Workflow field | Reference                        | Use                                            |
| -------------- | -------------------------------- | ---------------------------------------------- |
| Call ID        | `trigger.call.callId`            | Identify an attempt when available.            |
| Direction      | `trigger.call.direction`         | Restrict outbound follow-ups to `outbound`.    |
| Disposition    | `trigger.call.disposition`       | Choose the follow-up branch.                   |
| Outcome        | `trigger.call.outcome`           | Preserve existing broad outcome rules.         |
| End Time       | `trigger.call.endTime`           | Record when the call ended.                    |
| Duration       | `trigger.call.duration`          | Call duration; may be zero on failed attempts. |
| Summary        | `trigger.call.summary`           | Available summary text; may be empty.          |
| Session ID     | `trigger.call.ticket.ticketId`   | Link the attempt to its OpenCX session.        |
| Contact ID     | `trigger.call.ticket.contact.id` | Select the OpenCX contact for a follow-up.     |

<Warning>
  **Call Finished can run before the final summary is generated.** Log the outcome immediately if needed. Retrieve the finished session later before updating a CRM note with a final summary. A fixed delay alone is not proof that the summary is ready.
</Warning>

The `ticket` segment in workflow references is the existing field identifier for the session. Keep it unchanged in expressions.

## Webhooks and repeat attempts

External receivers can use [`phone_call.ended`](/api-reference/webhooks/types#phone-call-ended). Its optional `call_id` and `disposition` fields describe the attempt; workflow fields use `callId` instead. Check the actual payload before building rules for a human-call or legacy calling route.

A session may contain multiple attempts. Each AI call attempt can trigger its own **Call Finished** workflows; repeated completion events for the same attempt do not run them again. Store the attempt identifier alongside any CRM note or follow-up you create, and make your receiver handle repeated delivery without repeating that side effect. When a call ID is missing, review the event rather than grouping every call from that customer under one permanent deduplication key.

Continue with [Follow-up workflows](/phone/follow-up-workflows) for WhatsApp, callbacks, and CRM logging.