> 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/via-dialogue-studio/waiting-queue-node.md). # Waiting Queue node Reference for the Dialogue Studio Waiting Queue audio trigger, its configuration, output objects, and audio-session scope. {% hint style="warning" %} Waiting Queue triggers when an incoming audio call enters the waiting queue. It supports audio sessions only and is not the Enqueue routing action. Use the connection configuration documented below. Any linked known-issue workaround applies only to the exact bundles named in that issue. {% endhint %} ![Release note illustration](https://2382362027-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgIhRKIrtrwqPt8cNlAy6%2Fuploads%2Fgit-blob-e4f48ede60a9b84b06240f4afd67fe4b3ab65ca8%2Fe7f8bd717805fa48.png?alt=media) The Waiting Queue node triggers when an incoming audio call enters the waiting queue. Only audio sessions are supported. ### Configuration * **Server** ([any-red-config](https://atlas.anywhere.now/contact-center-configuration/building-your-callflow/via-dialogue-studio/waiting-queue-node#any-red-config)) - Configuration for UCC connection. * **Filter** (*string*) - Only selected conversation type will be passed on. ### Output Object – Customer Session (top) * **session.id** (*string*) - Identifier to recognize session. * **session.sipUri** (*string*) - Sipuri that the customer used to call the UCC. * **session.type** (*string*) - Type of session, will be 'audiovideo'. * **session.state** (*object*) - Object containing name and cancellation ID for current state. * **endpoint** (*object*) - (optional) Object containing information about the endpoint where the call entered the UCC. ### Output Object – Position Change (bottom) * **session.id** (*string*) - Identifier to recognize session. * **queue.real** (*number*) - Current position in the queue for session. * **queue.best** (*number*) - Best position in the queue for session till now. * **queue.previousReal** (*number*) - Previous value for real position, -1 when there is no previous real entry. * **queue.previousBest** (*number*) - Previous value for best position, -1 when there is no previous best entry. ### Details The output can be used as a trigger to play Queue Position messages, informational messages, or waiting music to the Caller. It is also possible to let the Caller leave a call back request, transition the call to another queue, or execute any other action part of the “Action” node to offer the Caller an escape when it is waiting in the Queue longer than expected. The sample that is included in Dialogue Studio will give you a head-start to build your own Queue strategy. ## any-red-config This configuration node connects Core nodes to a Unified Contact Center (UCC). Select it in the **Server** setting of the nodes that use the connection. ## Details Before configuring a flow, confirm the selected node's transport and the active configuration source for your environment. Use the connection details provided during provisioning. Applicability depends on that transport and configuration source, not the connect model alone. For Core nodes using the HTTP/SignalR plugin connection, configure **Server** with the Core service URL, including the plugin listener port, and the UCC name. Use the HTTP or HTTPS scheme configured for that listener. The editor URL you open in your browser is not this service endpoint. For another transport, use its provisioned connection details rather than assuming these listener settings apply. For the HTTP/SignalR plugin path, OnePortal assigns a separate Dialogue Studio plugin port to each UCC during provisioning. Use the assigned port with the service URL and UCC name. Sharing a listener port is also supported for this plugin path, but is not standard OnePortal provisioning. Do not change an assigned port without coordinating with AnywhereNow. Align all affected connections and dependent network configuration when changing it. For this HTTP/SignalR plugin connection, use `http://:`, or the equivalent `https` URL when HTTPS is configured. Enter the UCC name separately. The UCC name scopes normal callflow events and actions, not generic [Event Bus](https://atlas.anywhere.now/contact-center-configuration/building-your-callflow/via-dialogue-studio/core-nodes#eventbus-event-scope) events. Only one active Dialogue Studio connection controls a UCC's call sessions. When multiple instances connect, the priority settings below determine which connection controls normal callflow events and actions. These rules do not provide per-UCC filtering of generic Event Bus events. ## Priority When there are multiple Dialogue Studio instances connected to the same UCC, only the instance with the highest `priority` will be able to control sessions via trigger nodes (such as the "Incoming conversation"). For instances with lower priority, the trigger nodes will not fire. The `priority` can be set under the advanced configuration. If you plan to connect multiple Dialogue Studio instances, it is recommended to increase the `priority` of your production instance. It is not recommended to increase the priority for Development or Test environments. If multiple instances with the same `priority` connect, then only the one that is the first to connect will be the instance where the trigger nodes will fire. The maximum value for `priority` is 999 --- # 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/via-dialogue-studio/waiting-queue-node.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.