> For the complete documentation index, see [llms.txt](https://docs.ixhello.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ixhello.com/ixhc2/enhanced-error-handling-disconnect-logic.md).

# Enhanced Error Handling, Disconnect Logic

### Overview

This release introduces enhanced flow control capabilities that improve how errors, disconnects, and subflows are managed within a conversation flow. These enhancements allow developers to build more resilient and maintainable flows by providing dedicated handling paths for unexpected errors and caller disconnections, while also improving the subflow authoring experience.

***

### Error Handling in Flows

Flows can now leverage a dedicated Error Exit path to gracefully handle failures that occur during execution.

#### Benefits

* Prevents abrupt flow termination when an error occurs.
* Allows custom error recovery logic.
* Improves customer experience through controlled messaging.
* Helps maintain flow continuity after error handling.

#### How It Works

* A flow begins execution from the Start Node.

<figure><img src="https://4187494610-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFe4cpY1jy0FJ4kgC7wSx%2Fuploads%2FCJ1XByLloccXlUZCRkKm%2Fimage.png?alt=media&amp;token=d912521a-5fb4-481b-a0f5-e807862074dd" alt=""><figcaption></figcaption></figure>

* If an error occurs in a node (for example, an API Call Node), the flow automatically transitions to the Error Exit path.
* Custom logic can be configured on the error path, such as:
  * Playing an error message.
  * Setting variables.
  * Logging information.
  * Redirecting the flow.

<figure><img src="https://4187494610-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFe4cpY1jy0FJ4kgC7wSx%2Fuploads%2FbrwLPybhl1UKlv5cV6YW%2Fimage.png?alt=media&amp;token=d2f12ef3-4c2c-48b1-ab11-98c29de54d19" alt="" width="372"><figcaption></figcaption></figure>

* Once the error handling sequence completes, the flow can continue with the remaining conversation logic.

<figure><img src="https://4187494610-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFe4cpY1jy0FJ4kgC7wSx%2Fuploads%2F31zjClTeiGXlYVhYg8mx%2Fimage.png?alt=media&amp;token=11b21966-2a35-4d3b-b9d8-b37e6c3b1531" alt=""><figcaption></figcaption></figure>

#### Important Notes

* Existing flows are **not impacted** by this enhancement.
* Existing error-handling configurations continue to function as before.
* Developers can optionally enhance older flows by configuring the new error exit behavior.

***

### Disconnect Handling

A new Disconnect Exit path allows developers to define actions that should execute when a caller disconnects unexpectedly.

<figure><img src="https://4187494610-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFe4cpY1jy0FJ4kgC7wSx%2Fuploads%2FCH7t011VmgfYTjiSeYsW%2Fimage.png?alt=media&amp;token=14fe2619-1187-4c29-9eff-8c3e40a7eec8" alt=""><figcaption></figcaption></figure>

#### Purpose

When a caller leaves the interaction, there is no further opportunity to interact with the user. Instead, the system can execute backend processing tasks before ending the session.

#### Supported Nodes in Disconnect Logic

Since customer interaction is no longer possible after a disconnect, only non-user-facing nodes are permitted in the disconnect path.

Supported nodes include:

* Set Node
* API Call Node
* Branch Node
* Flow Node (Subflow Call)
* End Node

<figure><img src="https://4187494610-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFe4cpY1jy0FJ4kgC7wSx%2Fuploads%2FfmHYpOaAWmMIylRHbGs1%2Fimage.png?alt=media&amp;token=3f273153-68a9-455e-bc7e-b85c473739e8" alt=""><figcaption></figcaption></figure>

#### Unsupported Actions

The following actions are not allowed in the disconnect path because the caller is no longer present:

* Playing prompts
* Say nodes
* Transfers
* Any customer-facing interaction

#### Error Handling Within Disconnect Logic

To prevent infinite processing loops:

* Errors occurring within the Disconnect Exit path do not trigger the Error Exit path.
* If an error occurs during disconnect processing, the flow immediately terminates and moves directly to the End Node.

***

### Subflow Error Management

Subflows are responsible for managing their own exceptions.

#### Key Behavior

* Errors occurring inside a subflow must be handled within that subflow.
* Error handling does not automatically propagate back to the parent flow.
* This ensures clearer ownership and predictable flow behavior.

#### Recommendation

Always implement proper error handling within individual sub flows to avoid unexpected failures.

***

## Demo Scenario

The following example demonstrates the new functionality:

#### Flow Execution

1. The caller enters the main flow.
2. The flow reaches an API Call Node.
3. The API call generates an error.
4. Control transfers to the Error Exit path.
5. An error message is played to the caller.
6. After error handling completes, the flow continues normally.
7. The caller reaches a survey implemented through a Sub flow Node.
8. The survey subflow executes and returns control to the parent flow.
9. The interaction completes successfully.

#### Disconnect Processing

If the caller disconnects during the conversation:

1. The Disconnect Exit path is triggered.
2. Backend actions execute, such as:
   * Variable updates
   * Business logic execution
   * API logging calls
3. The flow reaches the End Node and terminates.

***

## Best Practices

* Configure Error Exit paths for critical nodes such as API calls.
* Use Disconnect Exit paths for logging, cleanup tasks, and backend processing.
* Handle errors within every subflow independently.
* Hide transcripts for authentication and security-related subflows.
* Utilize direct subflow navigation to speed up development and troubleshooting.
* Keep disconnect logic limited to non-customer-facing actions.

***

## Conclusion

These enhancements provide greater flexibility and reliability in flow execution by introducing dedicated error and disconnect handling mechanisms. Combined with improved subflow management features such as transcript hiding and direct navigation, developers can create more secure, maintainable, and fault-tolerant conversation experiences while improving overall development efficiency.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ixhello.com/ixhc2/enhanced-error-handling-disconnect-logic.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.