> 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/contact-center-configuration/building-your-callflow/route-calls-and-queue-messages.md).

# Route Calls and Queue Messages

Configure routing rules and queue messages so callers reach the right branch, queue, or destination.

Routing rules decide whether a caller follows the normal interactive voice response (IVR), enters a queue directly, or is redirected based on who called or which endpoint was called. Queue messages define what callers hear while they wait.

## Prerequisites

Before you configure routing rules, make sure:

* the required skills and IVR branches already exist
* the relevant endpoints are configured
* the target users or entry points that routing rules depend on are already known

## Choose the routing mode

The source distinguishes two routing patterns.

### Unified Contact Center (UCC) routing

Use UCC routing when the caller is contacting the contact center directly and routing should change based on the caller address or the endpoint that received the call.

| Field            | Use                                                          |
| ---------------- | ------------------------------------------------------------ |
| `Title`          | Notes for the rule                                           |
| `ExactMatch`     | Disables regular expression (regex) matching for `MatchFrom` |
| `MatchFrom`      | Matches the caller address or phone number                   |
| `Action`         | Defines what the rule does after a match                     |
| `Skill`          | Routes directly to a queue skill                             |
| `ParentQuestion` | Starts the caller at an IVR branch                           |
| `MatchEndpoint`  | Limits the rule to selected routing-enabled endpoints        |
| `Order`          | Sets rule evaluation order                                   |
| `Active`         | Enables the rule                                             |

### Inbound routing

Use inbound routing when a caller is trying to reach an individual agent directly and the system should intercept that call and route it elsewhere.

| Field               | Use                                                             |
| ------------------- | --------------------------------------------------------------- |
| `Title`             | Notes for the rule                                              |
| `MatchFrom`         | Matches the caller identity                                     |
| `MatchTo`           | Matches the called address or Uniform Resource Identifier (URI) |
| `Action`            | Defines what the rule does after a match                        |
| `Skill`             | Routes directly to a queue skill                                |
| `ParentQuestion`    | Starts the caller at an IVR branch                              |
| `Order`             | Sets rule evaluation order                                      |
| `ReferredBy Callee` | Controls the transferred-by identity behavior                   |
| `Active`            | Enables the rule                                                |

{% hint style="warning" %}
Current verification supports routing behavior, queue settings, and Microsoft Teams-aware telephony selection. Do not rely on older source wording that ties inbound-routing enablement to unrelated recording settings.
{% endhint %}

## Configure secure destinations

Use secure destinations when a specific telephone number or SIP address should make an audio dialogue secure after that destination joins the dialogue. This is useful for call paths where sensitive information may be exchanged, such as payment handling or confidential counselling.

Configure secure destinations in the `SecureDestinations` list.

| Field         | Use                                                                                                                  |
| ------------- | -------------------------------------------------------------------------------------------------------------------- |
| `Title`       | Describes the secure destination.                                                                                    |
| `Destination` | Stores the secure SIP address or telephone number. Use a value such as `sip:user@example.com` or `tel:+31201234567`. |

The secure-destination behavior can be triggered when a configured destination joins through call handling such as:

* blind transfer
* consultative transfer
* adding a participant through WebAgent call controls
* consult and transfer through WebAgent call controls
* skill transfer
* forward routing

When the dialogue becomes secure, the platform keeps the customer and secure destination in the dialogue and removes other participants that should no longer remain in the secured call path. If the agent is part of the completed transfer path, the agent may remain according to the transfer trigger.

{% hint style="warning" %}
Secure destinations are UCC-level configuration. If calls move between UCCs, validate the exact call path before relying on secure-destination behavior across the full transfer or forward journey.
{% endhint %}

## Forward to a fixed non-agent destination

Use a Dialogue Studio **Forward** action when an incoming flow must send the conversation directly to a fixed non-agent destination, such as a reception desk, external service, SIP address, or telephone number.

Use **Preferred Hunt** instead when the target is an agent and the conversation should respect contact-center availability and routing logic.

For the broader Dialogue Studio action-node context, see **Dialogue Studio core nodes**.

{% content-ref url="/pages/8yQ45O2XttelAa6G6IVv" %}
[Dialogue Studio core nodes](/contact-center-configuration/building-your-callflow/via-dialogue-studio/core-nodes.md)
{% endcontent-ref %}

### Dialogue Studio Forward Reporting

For direct SIP or external-number forwarding, the **Forward** action uses an internal routing queue named **Temporary forward skill**. That name may appear in Call Detail Records (CDRs), UCC logs, and Call Summary reporting, even though it is not an administrator-configured skill.

If reporting needs a business-specific skill name, use a dedicated configured skill for that routing design rather than relying on the temporary name.

## Useful matching patterns from the source

The source includes reusable matching patterns such as:

* match all
* match all except a country-code prefix
* match multiple values with one expression
* match internal or external callers

Use only the regex patterns your administrators can support operationally. If a simple exact match is sufficient, prefer it over a more complex expression.

## Queue message structure

The queue-message source splits caller prompts into four buckets:

* entering-queue messages such as welcome, closed, or holiday behavior
* IVR choice questions
* callback queue prompts
* waiting-queue messages such as queue-position announcements

Queue prompts can use typed text or uploaded audio files. In Atlas, describe these as administrative prompt-building options rather than as raw markup syntax.

## Related settings

These settings affect routing and queue behavior:

| Setting                             | Use                                                                                       | Value guidance                                                                          |
| ----------------------------------- | ----------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
| `EnableRoutingOutsideBusinessHours` | Controls whether routing rules apply when the contact center is closed.                   | Default `True`; set `False` when routing rules should apply only during business hours. |
| `OverflowThreshold`                 | Controls when overflow behavior applies because too many callers are in queue.            | Default `999`.                                                                          |
| `QueueBusyTimeOut`                  | Controls when the extra Message Busy prompt is introduced while the caller waits.         | Default `60` seconds.                                                                   |
| `QueueBusySpeechWaitTimeout`        | Controls the delay between queue-position and queue/busy prompts.                         | Default `5` seconds.                                                                    |
| `QueuePlayList`                     | Defines the playlist used while the caller waits in queue.                                | Use a playlist prepared for the customer environment.                                   |
| `UseTeamsHunter`                    | Selects the Teams hunter path for environments that require Teams-based hunting behavior. | Use only when approved for the environment.                                             |

The queue flow described in the source alternates position prompts, queue messages, and the extra busy message after the timeout threshold is reached.

## Verification

After configuring routing rules and queue messages:

1. Test one route that matches the normal caller path.
2. Test one route that matches a special caller or endpoint pattern.
3. Confirm queue prompts play in the intended order.
4. Confirm timeout-based queue prompts start at the expected point in the wait cycle.


---

# 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/contact-center-configuration/building-your-callflow/route-calls-and-queue-messages.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.