> For the complete documentation index, see [llms.txt](https://atlas.anywhere.now/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atlas.anywhere.now/product-reference/dialogue-studio/dialogue-studio-example-flows/configure-catch-node.md).

# Configure a catch node

Build a flow in Dialogue Studio that uses a catch node to handle a failing Enqueue node and fall back to a working skill.

This example builds error handling using a Catch node. If a node throws an error while handling a message, the flow normally halts. A Catch node lets you handle that error with a dedicated fallback flow instead. There is no importable flow for this example: build it node by node as described below.

## What it does

A Catch node is scoped to a specific Enqueue node. If that Enqueue node errors, for example because the target skill does not exist, the Catch node activates, plays a message telling the customer something went wrong, and enqueues the customer to a fallback skill that is known to exist.

## Prerequisites

* A UCC configured with Dialogue Studio.
* A working fallback skill that you are certain exists, since the whole point of this pattern is to route to a skill that will not itself fail.

## Preview

![Catch node flow](https://2627137428-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FscZpnEdBjDgQmlVn1iLr%2Fuploads%2Fgit-blob-730c9e4598ae8cede5f244ff758b722a56c9e9c8%2Fcatch.png?alt=media)

## Build the flow

### 1. Catch node

Drag and drop a Catch node. Open it, switch to **selected nodes**, and select the Enqueue node you want to catch errors from.

### 2. Say node

Drag and drop a Say node and connect it to the end of the Catch node. Set the message to notify the customer that something went wrong.

### 3. Enqueue node

Drag and drop an Enqueue node and connect it to the end of the Say node. Set the skill to a skill name that you know exists, as a fallback.

## How the flow works

* The Catch node only activates when the selected Enqueue node throws an error, for example when the configured skill does not exist.
* The Say node informs the customer that something went wrong before the fallback occurs, so the customer is not silently transferred without explanation.
* The fallback Enqueue node routes the customer to a skill that is not expected to fail, giving the customer a safe path out of the error.

## Safe fallback behavior

The entire purpose of this pattern is the safe fallback: it exists specifically so an error in one Enqueue node does not halt the flow and strand the customer. Make sure the fallback skill used in the final Enqueue node is a stable, verified skill so the fallback itself does not fail.

## Verification

1. Temporarily point the monitored Enqueue node at a skill that does not exist, and confirm the Catch node activates, the Say node plays, and the customer is enqueued to the fallback skill.
2. Restore the monitored Enqueue node to its intended skill and confirm normal enqueue behavior resumes without triggering the Catch node.

## Related topics

Go to [Dialogue Studio example flows](/product-reference/dialogue-studio/dialogue-studio-example-flows.md) for the full gallery of example flows.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://atlas.anywhere.now/product-reference/dialogue-studio/dialogue-studio-example-flows/configure-catch-node.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.