Microsoft Teams Integration¶

Overview ¶

The Microsoft Teams Integration serves as a bridge between Microsoft Teams and Dataiku’s Generative AI capabilities. It allows users to interact with Dataiku Agents and LLMs directly within Teams, enabling seamless access to data insights and automated responses in both chats and channel conversations.

Key Features

Interactive Bot: Chat directly with Agents configured in Dataiku.
Azure Bot Service Integration: Use Azure Bot Service to connect Microsoft Teams to your Dataiku webapp backend.
Teams Conversation Support: Works in chats and in channel conversations where the app has been added.

Setup ¶

Pre-requisites ¶

The Microsoft Teams Integration is provided by the “Dataiku Agents on Microsoft Teams” plugin, which you must install. Please see Installing plugins.

You will need administrative access to Microsoft Azure and Microsoft Teams, alongside write permission in a Dataiku Project and code execution permission to configure the integration. If you use managed mode, you must also be able to grant the Azure Resource Manager and Microsoft Graph permissions required by the Azure identity used by DSS.

The Microsoft Teams Integration uses a webapp in DSS, with the backend relaying messages back & forth between Microsoft Teams and the Agent. Depending on the selected exposure mode, the messaging endpoint called by Azure Bot Service is either exposed directly by the DSS webapp or by an Azure Function proxy. The backend must be running to process events. Enable auto-start backend in the Edit tab to ensure it runs automatically.

DSS must have outbound network access. If you use public mode, DSS must also be reachable through an HTTPS URL so Microsoft Azure can call the messaging endpoint exposed by the webapp.

The webapp supports two Azure resource provisioning modes:

Managed by Dataiku DSS: DSS creates and manages the Azure Bot Service and Microsoft Entra app registration for you. This is the default and recommended mode.
User Managed: You create the Azure Bot Service and app registration yourself in Azure, then paste the bot credentials into the webapp. This mode is available only with public mode.

Exposure modes ¶

The webapp supports two exposure modes:

Public mode: Azure Bot Service sends incoming Teams activities directly to the DSS webapp messaging endpoint. This mode requires the DSS webapp endpoint to be reachable by Azure over HTTPS.
Proxy mode: Azure Bot Service sends incoming Teams activities to an Azure Function. The Azure Function validates the Bot Framework request and forwards it through Azure Web PubSub. The DSS webapp backend keeps an outbound Web PubSub connection open and receives the activities from there.

Use proxy mode when you do not want to expose the DSS instance, or the DSS webapp endpoint, directly to the public internet. In this mode, the public endpoint belongs to the Azure Function, not to DSS. DSS only needs outbound connectivity to Azure Web PubSub, so the instance can remain behind your existing network boundary while still receiving Teams messages.

Note

Proxy mode requires Managed by Dataiku DSS provisioning mode because DSS creates and configures the additional Azure resources used by the proxy.

Security ¶

In public mode, the plugin delegates Teams request authentication to the Microsoft Teams SDK. The webapp backend is initialized with the bot client ID, client secret, tenant ID, and messaging endpoint configured for this webapp, and the SDK validates incoming Bot Framework requests before they are processed by the plugin.

In proxy mode, the Azure Function is the only public endpoint used for Teams traffic. Before it forwards an activity to DSS over the Web PubSub, it:

Requires a Bearer token in the Authorization header.
Validates the JWT signature against the Bot Framework signing keys published by Microsoft.
Verifies the token issuer is https://api.botframework.com.
Verifies the token audience matches the bot application ID configured for this webapp, including the api://<bot-app-id> form.
Verifies token lifetime claims such as expiration and issued-at time.
Verifies the token serviceurl claim matches the serviceUrl in the incoming Teams activity payload.

These checks ensure that the proxy accepts Bot Framework traffic only for the bot configured by this webapp, and rejects unauthenticated or mismatched requests before they reach DSS.

After the Azure Function relays the activity, the webapp backend still processes the request through the Microsoft Teams SDK using the bot credentials configured for this webapp. In other words, proxy mode adds an Azure Function validation layer in front of DSS, but it does not bypass the SDK-level authentication and request processing done by the webapp backend.

In both public mode and proxy mode, you can also enable Restrict allowed Teams tenants to limit which Microsoft Teams tenants can interact with the bot. When this option is enabled, the plugin checks the tenant ID carried by the Teams activity and rejects requests from tenants that are not in the configured allowlist.

Proxy mode architecture¶

When proxy mode is enabled, DSS ensures that the configured resource group exists, then deploys and configures the following Azure resources:

A Microsoft Entra app registration and client secret used by the Azure Bot.
An Azure Bot Service resource with the Microsoft Teams channel enabled.
An Azure Function app that exposes the public messaging endpoint used by Azure Bot Service.
An App Service plan for the Azure Function.
An Azure Web PubSub service used as the relay between the Azure Function and DSS.
A storage account used by the Azure Function runtime and deployment package.

The request flow is:

A user sends a message to the Teams app.
Microsoft Teams sends the activity to Azure Bot Service.
Azure Bot Service calls the Azure Function messaging endpoint.
The Azure Function validates the Bot Framework bearer token, including the expected bot application ID and service URL.
The Azure Function publishes the activity to Azure Web PubSub.
The DSS webapp backend, connected outbound to Azure Web PubSub, receives the activity and dispatches it to the local Teams integration backend.
DSS calls the configured Agent or LLM and sends the response back through the Microsoft Teams Bot Framework.

The Azure Function validates the Bot Framework bearer token against the configured bot application ID and service URL before forwarding an activity to DSS. This means that the Azure Function is internet-facing, but it accepts Teams activities only for the bot configured by this webapp, while the DSS instance does not need a public inbound route for Teams traffic.

Managed by Dataiku DSS ¶

In managed mode, DSS provisions the Azure resources needed by the Microsoft Teams integration. You only need to configure an Azure identity with the right permissions and complete the webapp settings. DSS creates an Azure Bot Service, a Microsoft Entra app registration, and the related bot credentials. You do not need to manually create the bot in the Azure portal. In proxy mode, DSS also provisions the Azure Function, App Service plan, Azure Web PubSub service, and storage account used to relay Teams activities to DSS.

Configure Azure Provisioning¶

In the webapp Edit tab, fill in the Azure provisioning fields in order:

Azure Tenant ID: Microsoft Entra tenant ID where the bot application will be created.
Exposure mode: Select whether Azure Bot Service calls the DSS webapp directly, or uses proxy mode to relay incoming activities through Azure Function and Azure Web PubSub.
Provisioning Mode: Select Managed by Dataiku DSS. This is the only supported provisioning mode for proxy mode.
Identity type: Choose how DSS authenticates to Azure for provisioning.
- Service principal from plugin preset: DSS uses a reusable service principal identity configured by a plugin administrator. This preset provides the tenant, subscription, location, and service principal credentials. It can also enforce a resource group name.
- Default credentials, from environment or System/User Assigned Managed Identity: DSS uses the default Azure credential chain, such as environment variables or the managed identity of the machine running DSS.
- Service principal: DSS uses credentials entered directly in the webapp, along with the tenant, subscription, location, and resource group configured in the webapp.
Service principal identity: Required when you select Service principal from plugin preset.
Azure Tenant ID, Azure subscription ID, and Azure location: Required when they are not provided by the selected identity type.
Service principal client ID and Service principal client secret: Required only when you select Service principal.
Managed resources base name: Base name used for the Azure resources created by DSS. Changing this value later creates a new set of resources.
Resource group name: Optional explicit resource group name. If left empty, DSS derives it from the managed resources base name with the -rg suffix. If you use a service principal preset that forces a resource group name, the preset resource group can override the value entered in the webapp. A single resource group can host at most 25 Microsoft Teams integration webapps managed by this plugin.

Grant the Required Azure Permissions¶

The identity configured in the webapp must have both Azure Resource Manager permissions and Microsoft Graph permissions.

Azure Resource Manager permissions are granted through Azure RBAC, typically on the resource group used by the integration or on the whole subscription. In public mode, DSS needs permissions to create, update, and delete the managed Azure resources:

Microsoft.Resources/subscriptions/resourceGroups/read
Microsoft.Resources/subscriptions/resourceGroups/write
Microsoft.BotService/botServices/read
Microsoft.BotService/botServices/write
Microsoft.BotService/botServices/delete
Microsoft.BotService/botServices/channels/write

In proxy mode, DSS also needs these Azure Resource Manager permissions:

Microsoft.Resources/deployments/read
Microsoft.Resources/deployments/write
Microsoft.Resources/deployments/operationStatuses/read
Microsoft.SignalRService/WebPubSub/read
Microsoft.SignalRService/WebPubSub/write
Microsoft.SignalRService/WebPubSub/delete
Microsoft.SignalRService/WebPubSub/listKeys/action
Microsoft.SignalRService/WebPubSub/operationStatuses/read
Microsoft.SignalRService/WebPubSub/operationResults/read
Microsoft.Storage/storageAccounts/read
Microsoft.Storage/storageAccounts/write
Microsoft.Storage/storageAccounts/delete
Microsoft.Storage/storageAccounts/listkeys/action
Microsoft.Storage/storageAccounts/blobServices/read
Microsoft.Storage/storageAccounts/blobServices/write
Microsoft.Storage/storageAccounts/blobServices/containers/read
Microsoft.Storage/storageAccounts/blobServices/containers/write
Microsoft.Storage/storageAccounts/fileServices/read
Microsoft.Storage/storageAccounts/fileServices/write
Microsoft.Storage/storageAccounts/queueServices/read
Microsoft.Storage/storageAccounts/queueServices/write
Microsoft.Storage/storageAccounts/tableServices/read
Microsoft.Storage/storageAccounts/tableServices/write
Microsoft.Web/serverfarms/read
Microsoft.Web/serverfarms/write
Microsoft.Web/serverfarms/delete
Microsoft.Web/sites/read
Microsoft.Web/sites/write
Microsoft.Web/sites/delete
Microsoft.Web/sites/publishxml/action
Microsoft.Web/sites/config/read
Microsoft.Web/sites/config/write
Microsoft.Web/sites/basicPublishingCredentialsPolicies/read
Microsoft.Web/sites/basicPublishingCredentialsPolicies/write

You can grant these permissions through a custom role scoped to the configured resource group, or more broadly at the subscription level. The webapp View tab can generate an Azure RBAC custom role template for the current configuration. A built-in role such as Contributor can also work if it matches your organization’s security requirements.

Microsoft Graph permissions are granted separately in Microsoft Entra. DSS needs one of the following permissions so it can create and manage the Entra application used by the bot:

Application.ReadWrite.OwnedBy: minimal permission.
Application.ReadWrite.All: full permission.

The webapp View tab includes a Required Permissions tab showing the live permission status for the configured identity.

Complete the Remaining Configuration¶

In the webapp Edit tab, fill in the remaining settings:

DSS public base URL: Required only when public mode is selected. This is the base URL where this DSS instance is reachable. DSS uses it to build the messaging endpoint called by Azure Bot Service.
Restrict allowed Teams tenants: Enable this to limit the bot to specific Microsoft Teams tenants.
Allowed Teams tenant IDs: When tenant restriction is enabled, list the tenant IDs that are allowed to use the bot, one per line. If the app is installed in another tenant, users there will not be able to interact with it. DSS automatically allows the tenant where the bot is provisioned. If a Teams activity has no tenant ID, DSS allows it only for the Azure test web chat and rejects it otherwise.
Agent/LLM: Dataiku Agent or LLM to use for generating responses.
Conversation context limit and Conversation history period: Control how much conversation history the model can use.
Use reaction while loading: Enable this if you want the bot to add a Teams reaction to the incoming message while it is generating a response, then remove it when processing completes.
Reaction type: Choose the Microsoft Teams reaction ID to use while the bot is loading a response, for example think. See the Microsoft Teams reactions reference for the supported reaction IDs.

Start the Backend and Provision Azure Resources¶

In the webapp backend configuration:

Make sure Auto-start backend is enabled.
If public mode is selected, make sure Require authentication is disabled.
If proxy mode is selected, keep Require authentication enabled. The Teams endpoint is exposed by the Azure Function, not by the DSS webapp.

Save the webapp to apply the configuration and start the backend. When the backend starts, it checks the Azure credentials and permissions.

If the webapp restarts later and the managed Azure resources already exist, DSS automatically detects them by checking the tags it stored on the resource group, syncs with the existing deployment, and resumes processing Teams events. You do not need to reprovision the Azure resources after a webapp restart.

If the backend does not start automatically:

Go to the Actions panel on the right side of the screen.
Select Start backend to manually start it.

Note

In public mode on Dataiku Cloud, add the webapp ID to Administration -> Settings -> Security & Audit -> Other security settings -> Webapps -> Public webapps.

Once the backend is running and the Azure credentials are valid, open the webapp View tab and select Create Resources. Provisioning can take up to two minutes. Do not stop the backend while provisioning is in progress.

Managed provisioning creates:

One Azure Bot Service.
One Microsoft Entra app registration.

The configured resource group can host at most 25 Microsoft Teams integration webapps managed by this plugin.

If proxy mode is enabled, managed provisioning also creates:

One Azure Function app.
One App Service plan.
One Azure Web PubSub service.
One storage account.

When provisioning completes, continue with the test and installation steps below.

User Managed Azure Resources ¶

Use this mode when your organization requires Azure resources to be created and governed outside of DSS. In this mode, you create the Azure Bot Service and app registration yourself, then configure DSS with the resulting bot credentials.

Create the Azure Bot Service Manually¶

Navigate to https://portal.azure.com and create the bot resources. This is the bot that you will later install into Microsoft Teams to interact with the Dataiku Agent or LLM.

During setup, make sure you:

Create an Azure Bot resource. If you choose Create new Microsoft App ID, Azure will also create the related App Registration. You can also create the app registration in advance and link it during bot creation.
Under Azure Bot -> Settings -> Configuration, set Messaging Endpoint to your DSS public base URL plus the endpoint displayed in the Dataiku webapp setup page.
Under Azure Bot -> Settings -> Channels, add the Microsoft Teams channel.

Note

The full messaging endpoint must be reachable by Microsoft Azure over HTTPS.

If Microsoft Teams and the Azure Bot resource run in different tenants:

Go to the App Registration linked to the Azure Bot that you created.
In Azure Bot -> Settings -> Configuration, select Manage Password next to Microsoft App ID to open the corresponding app registration.

Under Manifest, make sure the JSON contains the following values:

"accessTokenAcceptedVersion": 2,
"signInAudience": "AzureADandPersonalMicrosoftAccount"

Save the manifest.

Generate App Credentials¶

To let Dataiku authenticate with your bot, create the application credentials in Azure:

Go to the App Registration linked to the Azure Bot that you created.
In Azure Bot -> Settings -> Configuration, select Manage Password next to Microsoft App ID to open the corresponding app registration.
Under Certificates & secrets, create a new client secret.
Copy the secret value immediately and store it somewhere safe. Azure will not show it again.
In the Overview tab, also copy the Application (client) ID.

Important

Treat your client secret like a password. Never share it or commit it to version control. If it is compromised, rotate it immediately in the Azure portal.

Configure the Visual Webapp with User-Managed Credentials¶

In the webapp Edit tab, configure the following:

Azure Tenant ID: Paste the Microsoft Entra tenant ID where your Azure Bot and app registration are hosted.
Provisioning Mode: Select User Managed.
Azure Bot Service Microsoft App ID (client ID): Paste the application client ID.
Azure Bot Service Microsoft App Password (client secret): Paste the bot client secret.
Agent/LLM: Select the Dataiku Agent or LLM to use for generating responses.

Save to apply your configurations.

When you save the webapp, the backend should automatically start (a notification indicates that the backend is starting).

If the backend does not start automatically:

Go to the Actions panel on the right side of the screen.
Select Start backend to manually start it.

In the backend configuration:

Make sure Auto-start backend is enabled.
Make sure Require authentication is disabled.

Note

For Dataiku Cloud, add the webapp ID to Administration -> Settings -> Security & Audit -> Other security settings -> Webapps -> Public webapps.

Test the Bot in Azure ¶

Before installing the app in Microsoft Teams, run a quick test in Azure to confirm that Azure Bot Service can reach the configured messaging endpoint.

In the Azure Bot resource, open Settings -> Test in Web Chat.
Send a message in the chat window. The Agent or LLM you configured earlier should respond.
Check the DSS webapp Logs tab if the bot does not respond.

Generate the Teams App Manifest ¶

Before you can install the Agent in Teams, you need a Teams app manifest. You can create one in the Teams Developer Portal or with the manifest creator available in the webapp.

Open the Manifest creator tab in the webapp.
Enter the Teams app details you want to use, such as the name and icons.
Select Create manifest zip to download the manifest.

Note

If you create the manifest in the Teams Developer Portal instead of using the webapp manifest creator, add the following resource-specific application permissions to the manifest so the bot can read conversation messages:

"authorization": {
  "permissions": {
    "resourceSpecific": [
      {
        "type": "Application",
        "name": "ChannelMessage.Read.Group"
      },
      {
        "type": "Application",
        "name": "ChatMessage.Read.Chat"
      }
    ]
  }
}

Install the App in Teams ¶

Upload the manifest to Microsoft Teams or to your organization’s app catalog.

In Teams, open Apps in the left sidebar, then select Manage your apps.
Select Upload an app, then choose the manifest zip file that you created earlier.

Note

You may need administrator approval before you can install the app.

Test the integration in Microsoft Teams, as per the Usage section below.

Usage ¶

In Microsoft Teams:

Open the bot in a chat, or add the app to a channel where you want to use it.
Send a message in the chat or @mention the app in a channel where it has been added.
Check the DSS webapp Logs tab if the bot does not respond.