> 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/queues/configure-queue-routing-rules.md).

# Configure queue routing rules

Configure routing rules that match caller or entry conditions and send sessions to the right queue or IVR branch.

Use queue routing rules when incoming sessions should follow a different path based on who is calling, which address was called, or which endpoint received the session.

This procedure covers routing rules, not queue creation or queue settings.

## Before you begin

* Confirm the destination queue or IVR branch already exists.
* Confirm which caller patterns, telephone numbers, or entry endpoints the rule should react to.
* Confirm who will test the rule against live or pilot traffic after it is saved.

{% hint style="warning" %}
Routing-rule changes can affect live caller handling immediately. Plan changes carefully and test them before broad rollout.
{% endhint %}

## Decide what the rule should match

A routing rule starts with a **match condition**.

Depending on the scenario, the rule can match:

* the caller identity or caller address
* the called number or target address
* the endpoint that received the session

Use the simplest condition that reliably separates the traffic you want to reroute.

{% hint style="info" %}
UI labels can differ between deployments. You may see field names such as `MatchFrom`, `MatchTo`, or `MatchEndpoint`. Use these fields to define the condition that must be true before the rule runs.
{% endhint %}

## Choose what should happen after a match

When a rule matches, it should send the session to the next handling point.

The routing actions are:

* route the session directly to a queue
* start the session at a specific IVR branch

Use queue routing when the caller should bypass the normal entry flow and go straight to a known handling path. Use an IVR branch when the caller should still hear a question or follow a guided choice path first.

Depending on the administration surface, these targets may appear with labels such as `Skill`, `ParentQuestion`, or similar routing-target names.

## Keep the rule order intentional

Routing rules are evaluated in order. The **first matching active rule** determines what happens next.

Good practice is to:

* place the most specific rules before broader catch-all rules
* keep exception cases above the default path
* review the order whenever a new rule is added

If a broad rule appears too early, more specific rules below it may never run.

## Limit a rule to selected endpoints when needed

Some deployments allow a rule to apply only to selected routing-enabled endpoints instead of all eligible entry points.

Use endpoint scope when:

* one number or entry path needs special routing
* a pilot route should affect only one endpoint
* the same contact center serves multiple entry paths with different behavior

If you do not need endpoint-specific behavior, keep the rule scope as simple as possible.

## Use pattern-based matching carefully

Some routing-rule surfaces support both exact matching and pattern-based matching.

Some deployments expose this choice through an `ExactMatch` option or similar label.

Prefer an exact match when:

* you are targeting one known number or address
* the rule should be easy to review and troubleshoot
* the traffic pattern is stable

Use pattern-based matching only when:

* multiple values must be handled by one rule
* the administrators supporting the contact center can maintain the pattern safely
* the pattern has been tested with both matching and non-matching examples

{% hint style="info" %}
If a simple exact match works, prefer it over a more complex pattern. This keeps routing behavior easier to support during live operations.
{% endhint %}

## Treat Direct Routing interception as a separate dependency

If the rule depends on Direct Routing interception, called-party matching, or direct-to-user redirection, complete the relevant Direct Routing prerequisites before configuring it.

Some redirected-call scenarios also expose a transferred-by-callee option. Configure it only when required for your redirected-call scenario.

Go to **Connect model: Direct Routing** for the prerequisite and routing-scenario guidance that belongs with that setup.

{% content-ref url="/spaces/8itFXJdndqu1dclywEFc/pages/P2EMkmV52Ncf5FcJC6rT" %}
[Connect model: Direct Routing](/connect-telephony/direct-routing.md)
{% endcontent-ref %}

## Create or update a routing rule

1. Open the routing-rules settings used by your deployment.
2. Add a new rule or open an existing rule for editing.
3. Enter the match condition for the caller, target address, or endpoint.
4. Choose the routing action.
5. Select the destination queue or IVR branch.
6. Set the rule order.
7. Enable the rule.
8. Save the change.

If your administration surface supports endpoint scoping or exact-match toggles, configure those only when the routing design requires them.

## Disable or remove a routing rule

Disable a rule first when you want to stop using it but still keep the definition for review.

Remove a rule only when:

* it is no longer needed
* no current traffic path depends on it
* the contact-center design has been updated to replace it

## Verification

1. Test one session that should follow the normal default path.
2. Test one session that should match the new or updated rule.
3. Confirm the matched session reaches the intended queue or IVR branch.
4. If endpoint scope is used, test both an in-scope and out-of-scope entry path.
5. Review the rule order again if a broader rule matched before the intended one.

## Related topics

Go to **Configure IVR routing for the SharePoint callflow** for the IVR-entry behavior used when a routing rule should start the caller at a question branch.

{% content-ref url="/pages/VX7kfkoVLglBFuDA7eBm" %}
[Configure IVR routing for the SharePoint callflow](/contact-center-configuration/building-your-callflow/via-sharepoint/configure-ivr-routing.md)
{% endcontent-ref %}


---

# 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/queues/configure-queue-routing-rules.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.