> 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/incoming.md). # Incoming phase in Dialogue Studio Use the incoming phase in Dialogue Studio to start an audio flow, apply IVR logic, and choose the first routing path. Use the incoming phase to control what happens when an audio call first enters the Unified Contact Center (UCC). This is the phase where Dialogue Studio can replace or extend the default interactive voice response (IVR) path with node-based routing logic. ## When this phase runs The **Incoming call** node starts the flow when an audio conversation enters the contact center. For normal incoming audio calls, UCC opening hours, holidays, and overflow are checked before Dialogue Studio. When these checks select closed-state or overflow handling, the incoming trigger does not fire. With **Connect**, eligible **Always open** endpoints or configured outside-hours routing can allow exceptions to closed-hours handling. With **Unify**, **Always open** does not bypass the opening-hours check: a closed UCC plays the configured closed message and ends the call before starting Dialogue Studio. The [Business Hours and Holidays nodes](/contact-center-configuration/building-your-callflow/via-dialogue-studio/business-hours-and-holidays-nodes.md#ucc-opening-hours-and-flow-routing) evaluate messages only after they reach the flow. They do not replace or disable the UCC's SharePoint opening-hours configuration. See that guide for Connect endpoint eligibility and remaining checks. | Flow element | Purpose | | --------------- | --------------------------------------------------------------------- | | `Incoming call` | Starts the flow for an audio conversation entering the contact center | | `Server` | Uses the saved UCC connection configuration | | `Filter` | Controls which conversation type is passed into the flow | ## Prerequisites * You can open the target Dialogue Studio flow for the contact center and edit the dependent configuration surfaces referenced on this page. * You have the browser/editor URL, the supplied connection details for the deployed transport, and the exact target UCC name. Capture these separately using [Manage Dialogue Studio deployment](/platform-administration/provisioning/provisioning/configurations/manage-dialogue-studio-deployment.md#capture-the-deployment-details). * The configuration owner has confirmed that Dialogue Studio is enabled for the target UCC and that any required provisioning work is complete. ## Set up the UCC connection and incoming trigger Complete [provisioning and connection-settings verification](/platform-administration/provisioning/provisioning/configurations/manage-dialogue-studio-deployment.md#verify-provisioned-plugin-connection-settings) before configuring the flow. The **Server** and **any-red-config** procedure below applies to the HTTP/HTTPS plugin connection. If the deployment uses Kafka-based connectivity, use the node connection setup supplied for that transport; do not substitute the HTTP plugin settings. 1. Open the supplied Dialogue Studio browser/editor URL and the flow for the target contact center. 2. Add an **Incoming call** node or double-click the existing node to open its properties. 3. Under **Server**, select the saved UCC connection for this contact center. If none exists, select **Add new any-red-config** and open its edit (pencil) control. 4. In the connection configuration, enter the supplied Core service endpoint, including its scheme and port, and the exact target UCC name. Use the provisioned values, not the browser/editor URL or another UCC's endpoint. 5. Save the connection configuration and select it under **Server** on the **Incoming call** node. 6. In this HTTP/HTTPS node setup, set **Filter** to **Audio/Video**, not **IvrQuestion (Audio/Video)**. 7. Select **Done** to save the node, connect it to the intended caller-handling branch, and select **Deploy** during the agreed change window. 8. Place a controlled test call to the target UCC. Confirm that the incoming node starts the intended branch and that the caller reaches the expected queue or exit path. Use the same saved UCC connection in the related callflow nodes. If the connection or trigger does not work, check [Troubleshoot Dialogue Studio](/contact-center-configuration/building-your-callflow/via-dialogue-studio/troubleshoot-dialogue-studio.md#check-the-service-endpoint-port-and-ucc) before requesting a configuration change. ### SharePoint settings for the Dialogue Studio plugin For environments using the Ucc.Creator SharePoint template as the active configuration source, verify the settings in [Manage Dialogue Studio deployment](/platform-administration/provisioning/provisioning/configurations/manage-dialogue-studio-deployment.md#verify-provisioned-plugin-connection-settings). Connection configuration is also required for Unify; this SharePoint inspection path does not establish its transport or configuration source. Where SharePoint is the active configuration source, the Dialogue Studio plugin bypasses the initial SharePoint IVR menu and sends the call to Dialogue Studio. You do not need to add an initial SharePoint IVR menu entry to trigger this path. Select plain **Audio/Video** in the **Incoming call** node, not **IvrQuestion (Audio/Video)**, when using the HTTP/HTTPS node setup above. These node controls are not a universal transport requirement. On **Connect**, do not remove reusable IVR questions just because the initial menu is bypassed. A Dialogue Studio **IVR Question** action can still call an existing question in the same UCC, and any intended SharePoint fallback must be reviewed and tested separately. This reuse is not a Unify path in the documented DC2025.02a scope. ## How to use this phase Use the incoming phase when the caller journey must be decided before the call enters the waiting queue. Common patterns in this phase include: * playing a welcome or announcement message * presenting an IVR choice * looking up data and routing on the result * choosing whether to queue or disconnect the caller ## Reuse IVR questions from the current contact center For **Connect**, the **IVR Question** action lets you call an existing SharePoint IVR question from the same contact center. {% hint style="info" %} In the documented **DC2025.02a** scope, the **IVR Question** option and **SharePoint IVR** are planned, not available, for **Unify**. For a Unify menu, configure prompts and branches in Dialogue Studio using [IVR Menu](/contact-center-configuration/building-your-callflow/via-dialogue-studio/ivr-menu.md), subject to its supported actions. Do not use SharePoint question reuse as the menu implementation. Check [Connect vs Unify](/set-up-dialogue-cloud-neo/connect-vs-unify.md) for the release scope. {% endhint %} On Connect, use the **IVR Question** action only with a question in the same UCC. If the flow tries to route to another UCC, the session fails. Use [Configure the Dialogue Cloud IVR](/contact-center-configuration/building-your-callflow/configure-ivr.md) to maintain those questions, prompts, and parent-child structure. ## Design notes for the incoming phase Keep the incoming phase focused on the first caller decision point. Good practice in this phase is to: * keep the first branch simple and easy to test * separate welcome messaging from routing logic where possible * confirm the fallback path when the flow does not hand the caller to a queue * test business-hours, holiday, and overflow behavior separately from the Dialogue Studio branch Use **No Action** only when the environment owner has confirmed the intended fallback for the phase. For Dialogue Cloud Neo (Connect), No Action can fall back to the default SharePoint IVR configured for the contact center. Do not use this as a Unify fallback path; SharePoint IVR is not available for Unify. Test the fallback explicitly before relying on it. ## Verification 1. Place a test call that should enter the Dialogue Studio flow. 2. Confirm the intended welcome or IVR branch plays first. 3. Test at least one branch that reaches the waiting queue. 4. Test one branch that exits without queueing the caller. 5. On Connect where SharePoint IVR is used, confirm the Dialogue Studio plugin bypasses the initial SharePoint IVR menu and any deliberately reused IVR question still works. On Unify, test the Studio menu branches directly; do not expect SharePoint question reuse or fallback. ## Related topics For Connect SharePoint IVR, go to **Configure the Dialogue Cloud IVR** to maintain the questions, prompts, and parent-child structure that this phase can call. {% content-ref url="/pages/zNzwN8TGn31nyCQ4fjl1" %} [Configure IVR](/contact-center-configuration/building-your-callflow/configure-ivr.md) {% endcontent-ref %} Go to **Route calls and queue messages** for the broader routing and queue actions that can follow this first-contact branch. {% content-ref url="/pages/ZO573ktrsGDDLCZRkVy3" %} [Route Calls and Queue Messages](/contact-center-configuration/building-your-callflow/route-calls-and-queue-messages.md) {% endcontent-ref %} Go to **Dialogue Studio core nodes** for node-level behavior that can affect routing, fallback, and output ports. {% content-ref url="/pages/8yQ45O2XttelAa6G6IVv" %} [Dialogue Studio core nodes](/contact-center-configuration/building-your-callflow/via-dialogue-studio/core-nodes.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/building-your-callflow/via-dialogue-studio/incoming.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.