> 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/channels-integrations/dialogue-studio-integrations/integrate-external-services-with-dialogue-studio.md).

# Integrate external services with Dialogue Studio

Connect external AI, Microsoft, and service-platform systems to Dialogue Studio by using a durable credential, request, and response pattern.

Use this page to connect external AI services, Microsoft data sources, and service-platform systems to Dialogue Studio when the flow needs to request data or hand work to another platform.

## Before you begin

* Confirm which external system owns the data or behavior that the flow needs.
* Confirm who manages the application identity, secret, token, or endpoint for that system.
* Confirm that the flow has a safe branch for authentication failure, timeout, or unusable responses.
* Validate the integration in a controlled test flow before you expose it to production traffic.

{% hint style="warning" %}
External integrations can fail because of permissions, missing configuration, timeouts, or endpoint changes outside Dialogue Studio. Always design and test a fallback route before you depend on an external service in production.
{% endhint %}

## Keep the common integration pattern

Across most external integrations, the durable structure is the same:

1. Prepare the application identity, credential, or external endpoint outside the flow.
2. Store the required connection values in the approved configuration surface.
3. Request the required authentication value or call the external endpoint.
4. Parse the response and map it into the next Dialogue Studio action.
5. Route failure, timeout, or invalid-response outcomes to a safe branch.

## Connect to external AI services

Use an external AI service when the flow needs prompt-based processing, intent evaluation, classification, or generated output that is not handled locally.

### Azure OpenAI

For a durable Azure OpenAI pattern:

* choose the model deployment outside Dialogue Studio
* store the endpoint and credential values securely
* send the request payload from the flow
* parse the result before you route or reply

### Google Dialogflow

For a durable Dialogflow pattern:

* prepare the external agent and training data outside Dialogue Studio
* prepare the required Google service-account credential and project ownership
* send the required text input from the flow
* authenticate the request
* route on the returned result and defined follow-up action

## Connect to Microsoft data sources

Use an application identity when the flow must query Microsoft business data from inside Dialogue Studio.

Treat systems such as Dynamics 365 as pattern examples rather than as dedicated Dialogue Studio product-owned setups unless your environment has stronger product-specific guidance.

### Microsoft Graph

For a focused, downloadable diagnostic example, use [Connect to Microsoft Graph as an application](/product-reference/dialogue-studio/dialogue-studio-example-flows/connect-microsoft-graph-application.md). It demonstrates directory lookup, not a complete caller-facing flow.

Typical pattern:

* register the application
* grant the required Microsoft Graph permissions
* request an access token
* use the returned data in a lookup, search, or decision step

### SharePoint through Microsoft Graph

Treat SharePoint through Microsoft Graph as a Microsoft Graph variant rather than as a separate platform pattern.

Before you depend on it:

* confirm the required Graph permissions
* confirm the data location the flow should query
* confirm how the flow behaves when the list, item, or expected field is not available

### Dynamics 365 or Dataverse with an application user

Use a Dynamics 365 application user pattern only when the flow must query Dynamics 365 or Dataverse directly instead of using CRM Service.

Before you build the flow:

* create or reuse a Microsoft Entra ID app registration approved for the customer environment
* grant the required Dynamics CRM / Dataverse permissions, such as `user_impersonation` when that model is approved
* create the matching application user in Dynamics 365 or Power Platform
* assign a security role that can read only the required tables and records
* store the client ID, secret, tenant ID, and environment URL through the approved secret-handling process

In the flow, request an access token, reuse it until it expires, call the Dynamics 365 Web API or Dataverse endpoint, and route no-result, multiple-result, and request-failure outcomes explicitly. Do not keep client secrets inside imported flow JSON or debug nodes.

## Connect to service-platform systems

Use the same pattern for service-platform integrations. Systems such as ServiceNow are examples of this pattern, not dedicated Dialogue Studio product-owned setup paths in this page.

* prepare the external service identity and endpoint
* authenticate the request
* send the required query or update call
* map the response back into the Dialogue Studio branch

For a ServiceNow incident lookup or creation pattern, confirm the ServiceNow URL, authentication model, and roles with the ServiceNow owner before building the flow. Route success, no-result, and request-failure outcomes separately. For example, an incident lookup should handle a successful response with no matching incident differently from a failed request, and an incident creation flow should verify the created-response status before continuing.

Keep the main admin page focused on the integration shape. Do not turn a single subsection into a full product-specific implementation guide unless that service later gets its own dedicated page.

## Keep permissions and payload handling visible

Before go-live, confirm:

* which permissions are required for the external system
* which credential owner is responsible for renewal or rotation
* which payload fields the next Dialogue Studio node expects
* which response size or delay behavior the flow must tolerate

When the external system returns more data than the flow needs, map only the values required for the next decision or reply.

## Verification

1. Confirm the endpoint, credential, and permission set match the intended external system.
2. Run one successful end-to-end test through the external integration branch.
3. Force at least one authentication, timeout, or invalid-response failure and confirm the fallback route works as designed.
4. Confirm the flow maps only the response values that the next node actually needs.
5. Record who owns credential renewal, permission review, and endpoint changes for the integration.

## Related topics

Browse the [Dialogue Studio example gallery](/product-reference/dialogue-studio/dialogue-studio-example-flows.md) for concrete integrations. For a separate caller-recovery pattern, see [Configure a Catch node](/product-reference/dialogue-studio/dialogue-studio-example-flows/configure-catch-node.md). Validate each pattern against your flow's errors and timeouts before production use.

Go to **Integrate Copilot Studio with Dialogue Studio** for a Dialogue Studio integration pattern that depends on current Microsoft bot connection values and fallback routing.

{% content-ref url="/pages/LwwgOPNpYktaNvgU9Ayg" %}
[Integrate Copilot Studio with Dialogue Studio](/channels-integrations/dialogue-studio-integrations/integrate-copilot-studio-with-dialogue-studio.md)
{% endcontent-ref %}

Go to **Configure advanced Dialogue Studio features** for the broader admin guidance on AI-driven routing and settings-driven flow behavior.

{% content-ref url="/spaces/gIhRKIrtrwqPt8cNlAy6/pages/tVbNw2DZ0Mb6w6i0kFlM" %}
[Configure advanced Dialogue Studio features](/contact-center-configuration/building-your-callflow/via-dialogue-studio/configure-advanced-dialogue-studio-features.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/channels-integrations/dialogue-studio-integrations/integrate-external-services-with-dialogue-studio.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.