Custom org-catalog Teams app renamed via Graph: the bot's 1:1 chat keeps showing the old name (sign-out briefly shows the new one)

Tom Carmi 10 Reputation points
2026-10-29T06:53:33.2933333+00:00

Setup

  • Multi-tenant bot (Azure Bot / Bot Framework), distributed as a custom app in the customer's org app catalog (distributionMethod = organization).
  • To rebrand it, the org admin uploads an updated app package via Microsoft Graph: POST /appCatalogs/teamsApps/{id}/appDefinitions (same app id / externalId; manifest name.short changed, version bumped).
  • Afterwards, GET /appCatalogs/teamsApps/{id}?$expand=appDefinitions shows a single definition with the new displayName and new version. The user's installedApps entry (personal scope) also shows the new displayName.

What users see

  • The app tile / app details show the new name.
  • In the chat list, the title of the existing 1:1 chat with the bot still shows the OLD name.
  • After signing out and back in, the new name appears briefly, then the chat list title flips back to the old name after a while.
  • The personal chat was most likely created before the rename.

What we ruled out

  • Our outgoing activities do not set from.name (no name field at all in the payloads; the bot posts via Bot Framework v3/conversations).
  • The Azure Bot resource has a different display name from the old name shown, so it is not the bot registration's name.
  • Only one app (the org-catalog app) is installed for the user; there is no second/store copy with the old name.

Questions

  1. Is the display name of a bot's 1:1 personal chat stored per chat on the server side (e.g. captured from the app manifest when the chat was created), rather than read from the current app definition?
  2. If the user (or admin) uninstalls and reinstalls the personal-scope app, does Teams create a new 1:1 chat with a new conversation id, or reuse the existing chat (and keep the old name)?
  3. Is there a supported way to refresh the bot's name on existing personal chats after an org-catalog app update, other than asking each user to clear their Teams cache?

Thanks!

Microsoft Teams | Development
Microsoft Teams | Development

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

0 comments

3 answers

Sort by: Newest
Most helpful Newest Oldest
  1. Ashlesha Pawar (Tata Consultancy Services Limited) 565 Reputation points Microsoft External Staff
    2026-10-29T11:26:21.85+00:00

    Hello

    I believe the app name is defined in the Teams app manifest (manifest.json), specifically under name.short. Since the updated name is already reflected in the app catalog and installed-app details, could we verify whether the existing 1:1 chat is expected to refresh its name automatically after the manifest update?

    I suggest reproducing the issue and checking whether it occurs only in existing chats or also in new chats. If the old name continues to appear, we can investigate further and escalate to Microsoft Support if needed, rather than classifying it as a confirmed bug at this stage.

    Was this answer helpful?

    0 comments
  2. Elena-VH 2,450 Reputation points Independent Advisor
    2026-10-29T07:19:06.2466667+00:00

    Dear Tom Carmi,

    Based on the behavior you described, it appears that the existing personal bot chat is retaining cached or previously persisted identity metadata. ​‌

    The fact that the new name is visible in the app catalog, app details, and installed Apps record, yet the chat list reverts to the old name after sign-in, points to a Teams-side chat identity cache.

    As far as Microsoft currently documents, there is no supported Graph or Bot Framework API that forces an existing personal bot chat to refresh its displayed name. Updating the app manifest and republishing the app is supported, but existing 1:1 chats may continue to show stale identity information.

    I would recommend testing with a brand-new user (one who has never installed the app) and verifying that the Azure Bot profile name, Teams manifest name, and app registration display name are all aligned.​‌

    If uninstall/reinstall and clearing the client cache do not resolve it, I recommend opening a Microsoft support case in the M365 Admin Center, as there is currently no documented method to force a refresh of an existing personal bot chat's display name. For reference: Get support for Microsoft 365 for business

    For more information: Teams Personal Bot Identity Cache issue

    Note: As a forum member, please understand that I cannot verify Microsoft's internal implementation details or confirm whether the chat name is stored per conversation on the server side.

    Thank you for your patience and understanding. If you have any questions or if I have misunderstood anything, please feel free to reach out.

    Was this answer helpful?

    0 comments

  3. AI answer

    2026-10-29T06:54:44.96+00:00

    There is no documented API or supported admin operation to rename an existing personal bot chat; keep the current bot ID, treat the stale title as a Teams service issue, and open a Microsoft support case if it must be corrected tenant-wide.

    Answers to the three questions

    1. Is the name stored on the existing chat?

    The observed behavior is consistent with persisted server-side conversation or participant metadata:

    • The catalog definition and installed-app projection already return the new name.
    • Sign-out temporarily shows the new name, but synchronization restores the old one.
    • Your outgoing activities do not supply from.name.

    However, Microsoft’s public documentation does not explicitly state that a personal bot chat captures name.short when first created, so that storage mechanism should not be treated as a documented contract.

    Graph exposes a 1:1 chat as a distinct chat resource and provides an operation to retrieve the chat associated with a particular user installation ^1^. Unlike a group chat, a oneOnOne chat has a fixed roster ^2^.

    2. Does uninstall/reinstall create a new conversation ID?

    Do not rely on it doing so. The documentation confirms that uninstalling a personal app disables bot messaging—messages sent by either side receive 403—but it does not promise deletion of the chat or creation of a new conversation on reinstall ^3^.

    Teams chat history is cloud-backed and normally returns after reinstalling the client, further distinguishing installation state from stored chat state ^4^. Consequently, uninstall/reinstall may reconnect the app to the existing 1:1 thread and preserve its old title.

    You can determine the actual behavior in a test account without assuming it:

    1. Before uninstalling, obtain the personal installation ID.
    2. Retrieve and record its associated chat ID:
    GET /v1.0/users/{user-id}/teamwork/installedApps/{installation-id}/chat
Authorization: Bearer {token}
    1. Uninstall and reinstall the app.
    2. Obtain the new installation ID and call the same endpoint.
    3. Compare the returned chat.id values.

    The least-privileged delegated permission for reading this relationship is TeamsAppInstallation.ReadForUser; the application permission is TeamsAppInstallation.ReadForUser.All ^1^.

    This test establishes what happened for that account, but it does not turn conversation replacement on reinstall into a supported guarantee.

    3. Can the existing title be refreshed centrally?

    No documented operation is available:

    • PATCH /chats/{chat-id} can update topic only when chatType is group; it cannot rename a oneOnOne chat ^5^.
    • Reposting the app package updates an organization-catalog app definition, but the update API does not document rewriting metadata on existing personal chats ^6^.
    • Installation/conversation events let the bot react to installation and membership changes; they do not expose a command for changing a personal chat title ^3^.

    Since the old value returns after synchronization, clearing the desktop cache is unlikely to provide a durable tenant-wide correction. It may rebuild local state, but it cannot edit server-side chat metadata.

    Do not change botId merely to force the rename

    Changing bots.botId creates a new bot identity and conversation chain, with permanent loss of the existing interaction history in the new thread. Microsoft’s validation guidance explicitly warns against changing the bot ID during an app update ^7^.

    That is appropriate only for an intentional identity migration where a new thread and loss of continuity are accepted—not as a repair for stale branding.

    Escalation data

    Open a Microsoft 365 support request and include:

    • Tenant ID and affected user IDs through the secure support channel.
    • Teams app catalog ID, manifest app ID, and unchanged botId.
    • Old and new manifest versions and name.short values.
    • The associated chat.id from the Graph operation above.
    • Timestamps showing when the new name appears and when it reverts.
    • Reproduction in Teams web and desktop.
    • Graph responses showing the current app definition and installed-app display name.

    This gives support enough information to distinguish a service-side conversation-metadata defect from a client cache issue without repeating the causes already ruled out.

    References

    1. Get chat between user and teamsApp
    2. chat resource type
    3. Conversation events for agents
    4. Corporate IT - impact of uninstalling MS Teams Enterprise and reinstalling on chats etc - Microsoft Q&A
    5. Update chat
    6. Update teamsApp
    7. Teams Store validation guidelines
    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.