Share via

Duplicate proactive notifications from both old and new bot after changing botId in a published Teams app (multi-tenant →single-tenant migration)

Yifan Shao 60 Reputation points Microsoft Employee
2026-06-09T22:42:13.5533333+00:00

Environment

  • Notification-only personal bot (isNotificationOnly: true, personal scope).
  • App published to the public Teams Store, distributed via staged rollout (rings R0 → R4/public).
  • Migrating the bot's Microsoft App ID from a multi-tenant app registration to a new single-tenant app registration (new Azure BotService resource).
  • Our backend sends proactive 1:1 notifications and, during the migration window, is configured to send via both the old and new bot AppIDs.

What we did

  • Created a new single-tenant 3P app + new ABS.
  • Updated the published manifest's botId to the new single-tenant bot ID and rolled it out R0 → R3.6.

Relevant manifest fields:

"id": "<teams-app-id>",

"bots": [

{

 "botId": "<new-single-tenant-bot-id>",

 "scopes": ["personal"],

 "isNotificationOnly": true

}

]

Expected behavior

- Users see the "new version available" banner; after clicking Update, only the new (single-tenant) bot delivers notifications.

Actual behavior

- Users in R1 receive duplicate notifications: the same message arrives in two separate 1:1 chats — one from the old bot, one from the new bot.

- This happens even for users who have NOT clicked Update.

- In contrast, when we update the same app per-tenant via Teams Admin Center, only the new bot receives messages. The old bot's chatthread is still visible but receives nothing.

Questions

  1. After botId changes in a published app and rolls out via staged store rollout, does the old bot remain installed/authorized for existing users? Is it expected that the old bot can still send/receive proactive 1:1 messages until the user explicitly uninstalls/reinstalls?
  2. Once the new manifest (new botId) rolls out to a ring, is the new bot authorized to proactively message (createConversation) all users who already have the app installed — before they click "Update"? Our observation suggests yes; is this by design?
  3. Why does a per-tenant manifest update via Teams Admin Center result in only the new bot being able to message (old bot stops delivering), while the staged public store rollout (in dev portal) leaves both bots able to message the same user? Does the TAC per-tenant updateuninstall/replace the old bot in personal scope while the store "Update" does not?
  4. What is the recommended, supported path to migrate a notification bot's App ID (multi-tenant → single-tenant) in a published store app without (a) duplicate notifications from both bots during the transition, and (b) stranding users who haven't updated?
Microsoft Teams | Development
Microsoft Teams | Development

Building, integrating, or customizing apps and workflows within Microsoft Teams using developer tools and APIs

0 comments

Answer accepted by question author

Teddie-D 18,055 Reputation points Microsoft External Staff Moderator
2026-06-10T01:12:48.06+00:00

Hi @Yifan Shao

Please note that we're not Microsoft support, this is a user-to-user support forum. Moderators here don’t have backend access to Microsoft systems, so we can only provide technical guidance based on the public resources and experience. 

What you are observing is consistent with how Teams handles bot identity, app installation, and update flows, although Microsoft does not document every aspect of this migration scenario very clearly. 

Regarding your question: 

1.Does the old bot remain installed/authorized after a botId change? 

In a Teams Store staged rollout, existing users may continue to be reachable through the old bot identity after the botId change. Based on the behavior you described, existing conversation references and installation state associated with the old bot appear to remain valid during the rollout period.

As a result, the old bot may continue to send proactive notifications until users transition to the updated app experience or the old bot is retired. This would explain why users can continue receiving messages from the old bot even after a new manifest version has been published.

2.Can the new bot proactively message users before they click "Update"? 

Based on your observations, Teams appears to allow the new bot identity to establish proactive conversations with users even before they manually click the Update banner.

This aligns with the documented requirement that proactive messaging depends on the app being installed for the user. However, Microsoft does not clearly document this specific bot migration scenario, so it is difficult to state the exact internal behavior with certainty.

3.Why is Teams Admin Center behavior different? 

The most likely explanation is that TAC app updates and Store staged rollouts use different installation-update paths. The difference is due to how the update is applied:  

Teams Admin Center (tenant upload)  

  • Admin-driven update  
  • Appears to replace or override the existing installation more directly
  • Old bot stops receiving messages  

Teams Store staged rollout  

  • Update is delivered through the Teams client update process.
  • Existing users may continue to be reachable through both the old and new bot identities during the transition period.
  • Old and new bot identities can temporarily coexist  

This is consistent with the fact that proactive messaging is not strictly tied to the visible client version alone.

You effectively have:

  • Old bot still holding valid conversation references
  • New bot already able to create new conversations

If your backend sends the same notification through both App IDs, Teams delivers both notifications. The fact that the user has not clicked Update does not necessarily invalidate either path.

4.Recommended migration approach 

There does not appear to be a documented platform mechanism that guarantees automatic replacement of the old bot identity during a Teams Store staged rollout. As a result, coexistence may need to be handled at the application level.

The safest migration pattern is: 

  • Release the manifest with the new botId, keep the old bot operational. 
  • Do not dual-send notifications. 
  • Track which bot receives traffic from each user. 
  • Once a user is observed on the new bot, mark them as migrated and send only through the new bot. 
  • Continue sending through the old bot only for users not yet migrated. 
  • After sufficient rollout time, stop sending through the old bot and remove the old ABS. 

I hope this information is helpful. 

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".    

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. 

Was this answer helpful?

1 person found this answer helpful.
0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-06-09T22:42:43.8233333+00:00
    1. Yes. After changing botId in a published app, the old bot remains installed and can continue to send and receive proactive 1:1 messages for existing users. The Teams Store validation guidelines explicitly warn that changing the bot ID in an app update “leads to permanent loss of all user interaction history with the bot for existing users of your app and starts a new conversation chain with the new Bot ID.” This implies:
      • The old bot instance and its conversation(s) remain.
      • A new bot instance (with the new botId) starts a separate conversation chain.
      • Both bots can coexist and be able to send messages to the same user if the backend continues to use both IDs.
      The app update does not retroactively uninstall or de-authorize the old bot; it only associates the new manifest with the app going forward.
    2. Yes, this behavior is by design. When the botId is changed in the manifest and rolled out, the new bot is treated as a new bot instance. The app update conditions state that changing the botId requires consent because it changes app permissions. Once the updated app is installed/updated for a user (including via store rollout), the new bot is part of the app and can send proactive messages after installation. Because the old bot is not automatically removed, both bots can be authorized and able to send proactive messages to the same user until the old bot is explicitly removed or the backend stops using the old bot ID.
    3. The difference between per-tenant updates via Teams Admin Center and staged public store rollout is not fully documented in the provided context. However, the documented behavior that matters is:
      • Changing botId in the manifest creates a new bot instance and leaves the previous bot and its history intact and no longer associated with the app manifest.
      • The previous bot “doesn't belong to any app (as botId isn't mentioned in app manifest file) and hence app permission policies don't apply to it.”
      This explains why, after an app update, the old bot’s chat history remains but it is logically detached from the app. Any difference in observed behavior between TAC per-tenant updates and store rollout is not further detailed in the context.
    4. The recommended, supported path is to avoid changing the botId in a published app if possible. The Teams Store validation guidelines explicitly state:
      • “Ensure that the bot ID in the app manifest matches with bot ID in the last Teams Store published version of your app. Changing bot IDs in an app update leads to permanent loss of all user interaction history with the bot for existing users of your app and starts a new conversation chain with the new Bot ID. [Must fix]”
      This means:
      • Changing botId in a store app is discouraged and treated as a must-fix issue for validation.
      • There is no documented, supported pattern that both avoids duplicate notifications and avoids stranding users while changing botId.
      Within the documented guidance, the supported approach is:
      • Keep the same botId across app versions so that user interaction history and conversations are preserved and only one bot instance is active per user.
      • If a new bot resource is required (for example, for single-tenant vs multi-tenant changes), design the migration so that the same botId is retained in the manifest and Bot Framework registration, rather than introducing a new botId.
      Any migration that changes botId will, by design, create a new conversation chain and detach the old bot from the app, with the side effects described above. The guidelines treat this as something that must be corrected before publishing to the Teams Store.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.