> 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/set-up-dialogue-cloud-neo/design-planning-limits.md).
# Plan the deployment
Capacity limits, design rules, and deployment best practices for Dialogue Cloud.
Dialogue Cloud capacity depends on volume, frequency, and configuration. Review these limits before deployment planning — if your anticipated load approaches any of them, raise it with your AnywhereNow representative before proceeding.
{% hint style="info" %}
The platform allows some overdraft to avoid hard blocks on operations, but consistent overdraft is a prelude to re-scoping.
{% endhint %}
{% hint style="success" %}
**Before you begin:** Review these limits before starting deployment planning. If any limit is close to your expected load, raise it with your AnywhereNow representative before proceeding to configuration.
{% endhint %}
***
## Architecture overview
Dialogue Cloud uses a hierarchical deployment structure. Each **Region** hosts one or more **Instances** (one per customer). Each Instance contains one or more **UCC Services**, and each UCC service contains one or more **UCCs** (contact centers). Licensing, call routing, database assignments, and Session Border Controller (SBC) connections are scoped at these levels.
***
## Hierarchy: Region → Instance → Service → Contact Center
### Region
Each AnywhereNow customer requires at least one Dialogue Cloud **Instance** in each region where they deliver a Dialogue Management platform. Each regional Instance must contain at least one **UCC Service**, and each UCC Service must contain at least one **UCC** (Contact Center).
For Direct Routing telephone connections, a paired SBC link is required from the customer SBC to the regional Dialogue Cloud SBC. *(Connect model only)*
### Dialogue Cloud Instance
A Dialogue Cloud Instance identifies a customer administratively and defines the shared set of services — Dialogue Studio, WebAgent Service, Dialogue Manager, SBC IDs — used across all UCC Services for that customer in the region.
### UCC Service
A UCC Service is the collective of applications and web services specific to one Dialogue Cloud customer in one region.
UCC Service capacity and limits
| Limit | Value |
| -------------------------------------------------------------- | ----------------------------------------------------------------------- |
| Concurrent dialogue licences (base) | **10** (additional licences purchasable) |
| Minimum UCCs per Service | **1** |
| Maximum UCCs per Service | **50** |
| Maximum concurrent dialogues (no audio recording) | **500**, distributed across all UCCs |
| Maximum concurrent dialogues (with audio recording on any UCC) | **350**, distributed across all UCCs |
| Maximum additional endpoints across all UCCs | **300** |
| Secondary UCC Service permitted when | Minimum **25** concurrent dialogue licences purchased |
| Agent addresses | Unlimited (SharePoint list theoretical limit: 30 million items per UCC) |
### UCC (Contact Center)
Each UCC (Unified Contact Center) is a contact center configuration with its own parameters: business hours, text-to-speech (TTS) language, phone number endpoints, customer relationship management (CRM) plugins, and other settings. A UCC is not shared with other UCCs.
Each UCC requires its own SharePoint UCC Site.
***
## Single vs. multi-region deployment
| Scenario | Deployment |
| ------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| One channel (single global number, one chatline, one email address) | One instance, one UCC, one region — deploy in the region with the most anticipated end-customer traffic |
| Multiple channels across multiple regions (multiple numbers, email addresses, products, languages, offices, or countries) | Multiple instances, multiple regions |
{% hint style="info" %}
**Connect model:** For region-specific network requirements such as NAT Gateway IP ranges, see [Telephone Connection for Dialogue Cloud Neo (Connect)](/connect-telephony/direct-routing.md).
{% endhint %}
***
## Deployment rules
The following rules apply to all Dialogue Cloud deployments. Violations cause unpredictable behavior that is difficult to troubleshoot because failures often surface only after a service restart.
{% hint style="warning" %}
Incomplete or improper configurations, and mismatched version numbers of dependent building blocks, **will** cause errors. Follow these rules without exception.
{% endhint %}
### General rules
**Rule 1: A UCC connects to exactly one regional WebAgent Service.**
A running WebAgent Service keeps agent sessions in memory. If a UCC points to multiple WebAgent Services, unused services accumulate open dialogues indefinitely until the next restart, causing resource exhaustion.
***
**Rule 2: A WebAgent Service connects to exactly one regional Dialogue Manager.**
If two UCCs share a WebAgent Service but reference different Dialogue Manager URLs, the first UCC to push settings after a restart becomes primary. The second Dialogue Manager is silently ignored, causing inconsistent behavior across restarts.
***
**Rule 3: Do not connect multiple Dialogue Managers to the same database.**
Multiple Dialogue Managers sharing one database cause a race condition — both attempt to process the same record simultaneously. Use a regional component setup with one Dialogue Manager per database.
***
**Rule 4: Do not query the Dialogue Manager database directly.**
Direct queries — for example, from Power BI — can lock table records, preventing the Dialogue Manager or Dialogue Provider from accessing them. This causes missing messages and unprocessed conversations. Direct queries also degrade SQL performance, introducing latency. Query a read replica or a copy of the database instead.
***
**Rule 5: Do not leave UCCs partly configured.**
For example, do not leave the Dialogue Manager URL set to the placeholder value `"Enter connection string here"`.
Components (Dialogue Manager, Dialogue Provider, WebAgent Service) use **Primary Settings**: the first UCC to push its configuration after a restart becomes the active configuration. A partly configured UCC that starts first causes outages on all UCCs sharing the same component.
***
**Rule 6: Never set the plugin setting `Enabled` to `false` for Dialogue Manager or Dialogue Providers — delete the settings instead.**
`Enabled` is a primary setting. If a UCC with `Enabled = false` starts first, it disables the Dialogue Manager or Dialogue Provider for all UCCs using that component. If the component is not needed for a UCC, remove the plugin settings entirely rather than disabling them.
***
### Multi-region rules — WebAgent Service
**Applies when:** UCCs span multiple regions but only one region runs the WebAgent Service.
**Required action:** Migrate to regional WebAgent Services. Each region must have its own WebAgent Service URL.
**Why this matters:** It is not possible to update both regions simultaneously. If the region running the WebAgent Service is updated but the other region is not — or vice versa — the WebAgent Service may receive data in an incompatible format, causing an outage.
{% hint style="success" %}
An agent who works across UCCs in two regions can use both regional WebAgent URLs in separate browser tabs or windows.
{% endhint %}
***
### Multi-region rules — Dialogue Manager
**Applies when:** UCCs span multiple regions but only one region runs the Dialogue Manager and its database.
**Required action:** Migrate to regional Dialogue Managers, each with their own database.
**Why this matters:** When a Dialogue Manager is updated, it executes SQL schema migrations. A Dialogue Provider on a different version may then write data in an incorrect format — causing corruption — or fail to write data at all, causing message loss.
***
## What's next?
Return to the [setup overview](/set-up-dialogue-cloud-neo/initial-setup.md) to coordinate the applicable preparation work with the new-deployment or existing-customer path and the confirmed deployment model.
---
# 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/set-up-dialogue-cloud-neo/design-planning-limits.md?ask=&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.
