Clarification on Multi-Tenant Support for Single-Tenant Teams Bot Deployment

Question

Clarification on Multi-Tenant Support for Single-Tenant Teams Bot Deployment

Akshay Babar 65

Hi Team,

We are currently updating our Microsoft Teams bot implementation based on the recent deprecation of the multi-tenant bot configuration. As per the latest guidance, we are now creating the bot using a Single Tenant setup.

However, our requirement is to support multiple customer tenants (external organizations) using the same bot.

We would like clarification on the recommended approach for this scenario:

Is it mandatory to publish the app to the Teams App Store (AppSource / Org Store) for external tenant usage?

Alternatively, can we distribute the bot using a custom app package (ZIP) and allow customers to sideload/install it in their respective tenants?

If distribution via ZIP is possible, what changes or implementation steps are required to ensure the bot can support multiple tenants despite being configured as Single Tenant?

Are there any limitations or additional configurations required when using Single Tenant bots across multiple tenants?

This clarification is important for us to finalize our deployment and distribution strategy.

Thanks in advance for your guidance.

Regards, [Moderator note: personal info removed]

kagiyama yutaka 3,925 Reputation points

2026-05-10T05:24:09.1633333+00:00

I think you don’t need AppSource… single‑tenant bots run fine in other tenants if their admin allows custom apps… switching the Entra app to multi‑tenant doesn’t change the bot’s audience anymore

3 answers

Your answer

kagiyama yutaka 3,925 Reputation points

2026-05-10T05:24:09.1633333+00:00

I think you don’t need AppSource… single‑tenant bots run fine in other tenants if their admin allows custom apps… switching the Entra app to multi‑tenant doesn’t change the bot’s audience anymore

Answer 1

Vaibhav Tiwari 0

We have a problem with distribution. As it is not secure, for us to put the app in the market place for everyone to see.. Is there a safer appsource to distribute? Or some way that people could only see the app we published if we allow them?

Hin-V 16,155 Reputation points Microsoft External Staff Moderator

2026-06-26T23:00:59.65+00:00

Hi @Vaibhav Tiwari

Thanks for reaching out and sharing your concerns.

To help us support you more efficiently, could you please create a new thread on the forum and include the full details of your issue.

When posting, please make sure to include:

A clear description of your request.

Any additional support you may need.

Providing these details will help our team quickly understand your situation and offer the most accurate guidance.

Warm thanks.

Answer 2

Hin-V 16,155 Microsoft External Staff Moderator

Please note that our forum is a public platform, and we will modify your question to hide your personal information in the description. Kindly ensure that you hide any personal or organizational information the next time you post an error or other details to protect personal data.

Hi @Akshay Babar

Thank you for sharing your concerns.

Regarding to your concerns:

For publishing the app to the Teams App Store

As far as I know, publishing to the Teams App Store (AppSource) is not strictly mandatory, but it is strongly recommended and is the most reliable approach for supporting multiple external customer tenants with a single-tenant bot.

This method aligns with current guidance after the deprecation of multi-tenant bot creation, and it provides a scalable and fully supported way to distribute your bot across tenants.

Distribute the bot using a custom app package (ZIP) and allow your customers to sideload/install it in their respective tenants

It is technically possible. Your customers can upload the .zip package via the Teams Admin Center or sideload it directly in Teams. However, while this approach might work in some scenarios, it is not the recommended method for large-scale or production multi-tenant use. It requires manual installation in each tenant and depends on tenant policies that may block custom app uploads.

In addition, for cross-tenant scenarios, behavior can be inconsistent. While a single-tenant bot can still receive messages from users in other tenants once installed, some features (such as authentication flows, proactive messaging, or Graph-related scenarios) may not function reliably without proper consent and configuration.

For these reasons, AppSource/Teams Store remains the most reliable and supported method for cross-tenant distribution. It allows Microsoft to handle consent, provisioning, and installation flow across tenants, even though the bot itself remains single-tenant.

Changes or implementation steps are required to support multiple tenants when using ZIP distribution

In this scenarios, to support external tenants with a single-tenant bot, you may need to implement the following:

Ensure your bot logic is tenant-aware and can handle different tenantId values from incoming requests
Design proper tenant isolation and avoid mixing data between tenants

If your bot requires user authentication or Microsoft Graph access in your customer tenants, additional configuration (such as consent or alternative authentication models) might be required, since a single-tenant app does not natively authenticate users from other tenants.

Note that switching the Azure Bot itself to multi-tenant is no longer applicable for new implementations, as multi-tenant bot creation has been deprecated.

Limitations or additional considerations when using Single-Tenant bots across multiple tenants

When using single tenant bots across multiple tenants via ZIP distribution you might face several important limitations including:

Scalability and distribution challenges

Because ZIP deployment requires manual installation in every customer tenant and does not support self-service discovery.

Policy dependency
Since each customer tenant must allow custom app uploads and grant the required permissions.

Authentication and API access

Some authentication scenarios and Graph integrations require additional configuration and tenant-level consent.

Testing and maintenance

Cross-tenant validation and troubleshooting are more complex compared to AppSource distribution.

For Long-term supportability

AppSource is the only approach aligned with Microsoft’s long-term direction for cross-tenant app distribution.

I hope this helps.

Please feel free to correct me if I misunderstood your request. If you have any additional concerns, feel free to comment below. I would be more than happy to assist.

Note: Please follow the steps in [our documentation] to enable e-mail notifications if you want to receive the related email notification for this thread.

Akshay Babar 65 Reputation points

2026-05-07T10:08:23.9266667+00:00

I created the app in Tenant A, and my app registration and Bot Framework code are configured as multi-tenant. But, in the Azure Bot resource, I selected Single Tenant.

Now, while uploading the app ZIP in Tenant B, I am getting the following error.

How can we resolve this issue?
Akshay Babar 65 Reputation points

2026-05-07T15:38:55.78+00:00
Also, while sending a proactive message back to MS Teams through the bot, we are getting the below error.
[onTurnError] unhandled error RestError: Authorization has been denied for this request.

{

"name": "RestError",

"statusCode": 401,

"details": {

"message": "Authorization has been denied for this request."

},
Hin-V 16,155 Reputation points Microsoft External Staff Moderator

2026-05-07T20:02:56.1733333+00:00

Hi @Akshay Babar

Thank you for sharing the details

It looks like this issue is related to how Microsoft Teams and the Bot Framework enforce tenant boundaries and authentication.

Regarding the issue when uploading the app package in Tenant B, the message indicates that the app is being blocked because the webApplicationInfo.id (your Entra ID App Client ID) is registered in Tenant A, while you are attempting to install the app in Tenant B. For custom apps distributed via ZIP, many tenants enforce policies that require the app identity to belong to the same organization or be explicitly trusted. Since your app registration does not exist in Tenant B, the installation is being rejected, which is expected behavior.

The 401 “Authorization has been denied for this request” error during proactive messaging is also expected in this configuration. Your Azure Bot resource is configured as Single Tenant, so it authenticates using tokens issued by Tenant A. When the bot attempts to send a proactive message to a conversation in Tenant B, that token is not valid for the target tenant, and the Bot Framework therefore rejects the request.

It is also worth noting that your current setup uses a multi-tenant Entra ID app registration together with a single-tenant Azure Bot resource. In practice, this can lead to inconsistent behavior in cross-tenant scenarios as I mentioned earlier, as the bot runtime authentication remains scoped to a single tenant, and ZIP sideloading does not establish the required cross-tenant trust or provisioning in the destination tenant.

Regarding ZIP distribution, while it may be technically possible to sideload an app into another tenant, this approach might not guaranteed to work in cross-tenant scenarios. Installation may be blocked by tenant policies (as in your case), and even if installation succeeds, authentication and messaging scenarios may still fail due to tenant isolation restrictions. For this reason, ZIP deployment might be suitable only for internal or controlled testing scenarios.

For reliably support multiple external tenants, I would recommend you to keep the Azure Bot as Single Tenant and distribute the Teams app via AppSource or the Teams Store. This allows Microsoft to handle cross-tenant installation, consent, and service principal provisioning in each customer tenant, ensuring that authentication and messaging work correctly.

I hope this helps.
Akshay Babar 65 Reputation points

2026-05-08T16:16:04.8633333+00:00
Thank you for the response.

Regarding the issue, the app registration exists in Tenant A, and we are trying to upload/install the app in Tenant B.

For Tenant B, can we use the below admin consent URL to grant access to the app, or is there any other option available through ZIP upload?

https://login.microsoftonline.com/common/adminconsent?client_id={client_id}

Also, I have one more doubt.

Since the multi-tenant bot flow is deprecated, we created:

the App Registration as multi-tenant

the Azure Bot Resource as single-tenant

And in the Bot Framework code, we are using the tenant ID where the bot is hosted.

So going forward, while creating a new bot through the VS Code extension:

Do we first need to manually create the Azure Bot Resource and then deploy from VS Code?

Or will the provisioning flow automatically create the Azure Bot Resource as single-tenant?T
Hin-V 16,155 Reputation points Microsoft External Staff Moderator

2026-05-08T21:25:38.1266667+00:00

Hi @Akshay Babar

Thank you for your response.

Regarding the admin consent URL, using the /common/adminconsent endpoint might not resolve the issue you are encountering with ZIP sideloading. While this URL can grant permissions and create a service principal in Tenant B for a multi-tenant Entra ID application, it does not bypass Teams app installation restrictions. In your case, the error occurs before consent is even relevant, because Teams blocks the app during installation due to the webApplicationInfo.id belonging to a different tenant. In other words, admin consent can grant API permissions, but it does not allow a custom ZIP app from Tenant A to be treated as a trusted app in Tenant B.

Additionally, even if admin consent is granted, it does not address the second problem you are seeing with proactive messaging. Since your Azure Bot resource is configured as Single Tenant, the bot continues to acquire tokens from Tenant A only. When sending proactive messages to Tenant B, those tokens are not valid for that tenant, so the 401 “Authorization has been denied” error will continue to occur. This behavior is independent of admin consent and is tied to the bot’s single-tenant authentication scope.

Regarding your second question about the creation flow for a new bot, when using the Teams Toolkit or VS Code extension, the provisioning flow is designed to align with the current Microsoft model. Since multi-tenant bot creation is deprecated, new bots are provisioned using a single-tenant configuration by default. In most cases, you do not need to manually create the Azure Bot resource first, as the provisioning process will automatically create the required Azure resources, including the Azure Bot, in your tenant.

However, it is important to understand that even with a multi-tenant Entra ID app registration, the Azure Bot resource itself remains single-tenant, and cross-tenant behavior is not enabled through identity alone. It depends on how the Teams app is distributed and installed.

I hope this helps.
Hin-V 16,155 Reputation points Microsoft External Staff Moderator

2026-05-09T23:01:58.86+00:00

Hi @Akshay Babar

I hope the provided information were able to fully addressed your concern.

In case you require further assistance regarding this topic, feel free to reach out.

I would be more than happy to assist.

Looking forward to hearing from you.

Answer 3

A single-tenant Azure Bot can be used by multiple customer tenants; the key difference is how authentication and distribution are handled, not that each customer needs a separate bot.

From the current guidance:

Multi-tenant bot creation in Azure Bot Service is being deprecated after July 31, 2025. New bots should use SingleTenant or user-assigned managed identity going forward.
- For multi-tenant bots the configuration was:
  - MicrosoftAppType = MultiTenant
  - MicrosoftAppId = <bot app id>
  - MicrosoftAppPassword = <bot app password>
  - MicrosoftAppTenantId = <blank>
- Going forward, use single-tenant configuration instead.
For Teams distribution, the supported options for Microsoft 365-enabled Teams apps (including bots) are:
- Single-tenant distribution (org-only):
  - Upload and publish the app package via:
    - Teams client → Manage your apps → Upload an app → Submit an app to your org.
    - Teams Developer Portal.
    - Microsoft Teams admin center.
    - Microsoft Admin Center.
- Multitenant distribution (cross-tenant):
  - Publish via the Microsoft commercial marketplace (AppSource) using the Teams app manifest (v1.13 for Microsoft 365-enabled apps).
  - This is the standard way to make a Teams app available to multiple external tenants.
Sideloading / ZIP distribution:
- For testing and ALM, a customer or partner can sideload the .zip package that references a bot/agent:
  - “A customer or partner can sideload the .ZIP package … The .ZIP package can be uploaded via the Teams or Microsoft Admin Center and managed the same as for single-tenant agents in Copilot Studio.”
- This pattern is explicitly supported for multitenant agents in Copilot Studio and is analogous for Teams apps that include bots: the ZIP (app package) can be uploaded in another tenant if that tenant’s admin allows custom app upload.
- Bots in production should be added to Teams as part of a Teams app package, not by GUID, because adding by GUID “severely limits the functionality of a bot.”
What this means for the scenario:
- Is AppSource mandatory?
  - For broad, self-service, multitenant distribution to many external organizations, the recommended and supported approach is to publish to the Microsoft commercial marketplace (AppSource) as a multitenant Teams app.
- Can a ZIP package be used instead?
  - Yes, a ZIP (Teams app package) can be provided to specific customers, and their admins can upload/sideload it in their tenant via Teams or Microsoft Admin Center, provided their policies allow custom apps.
  - This is suitable for controlled or limited cross-tenant deployments (for example, a small number of customers or pilot programs).
- What is required to support multiple tenants with a single-tenant bot?
  - The bot itself is registered as single-tenant in Azure, but the Teams app package that references it can be:
    - Distributed privately (ZIP) to specific tenants, or
    - Published as a multitenant app via AppSource.
  - Each external tenant must:
    - Install the Teams app package.
    - Grant any required permissions/consent for the underlying Azure AD app.
- Limitations / additional configuration:
  - Multi-tenant bot creation is deprecated; use single-tenant or managed identity for new bots.
  - For production use across many tenants, AppSource-based multitenant distribution is the supported pattern.
  - For ZIP-based distribution, each customer tenant’s admin must explicitly upload and manage the app, and tenant policies (custom app upload, third-party app controls) must allow it.

In summary:

AppSource is the recommended route for scalable, multitenant distribution of a Teams bot.
Distribution via ZIP/sideloading is possible and supported for cross-tenant scenarios where the customer’s admin uploads the package.
The bot remains single-tenant in Azure; cross-tenant usage is enabled by how the Teams app package is distributed and installed, plus the necessary admin consent in each customer tenant.

References: