Teams channel delivers no activity to the bot, while Direct Line works on the same Azure Bot

Summary

A single-tenant Azure Bot receives and answers activities normally over Direct Line / Web Chat, but the Microsoft Teams channel delivers nothing at all. Messages sent from the Teams client are accepted by the Teams service — a server-side message ID is assigned and the message renders in the chat — yet no activity ever reaches Azure Bot Service or the bot's messaging endpoint. No error is surfaced anywhere.

Environment

Manifest bot section:

json

"bots"

Symptom — correlated timeline

Message sent from the Teams desktop client at 2026-08-06T15:32:56.552Z. Teams client diagnostic logs confirm it left the client and was acknowledged by the service:

15:32:56.534  SendMessage: posting client lie with cid: 7398136681493180706
15:32:56.552  SendMessage: sending message with cid: 7398136681493180706
                to conversation 19:<userObjectId>_<botAppId>@unq.gbl.spaces
15:32:57.198  chatServiceSubscriptionContainer: NewMessage: id 1786030376597,
                cid 7398136681493180706, type RichText/Html

The optimistic local echo was replaced by a server-assigned ID (1786030376597), so the Teams service accepted and re-broadcast the message.

For that timestamp:

• ABSBotRequests — no row with Channel == "msteams", at that time or anywhere on that day
• Application Insights on the bot's App Service — no request at all

No bot reply, no error, no delivery failure logged.

The bot is demonstrably healthy at the same period

A Web Chat test 24 minutes later, on the same Azure Bot resource and the same messaging endpoint, works end to end:

So the endpoint is publicly reachable, JWT validation succeeds, and the bot answers in a few milliseconds — over a channel that shares the same endpoint, the same App ID and the same credentials as the Teams channel.

Already ruled out

• Manifest botId matches the Azure Bot's Microsoft App ID exactly.
• scopes includes personal; isNotificationOnly is false.
• App is installed for the user — Teams shows Open, not Add, under Built for your org.
• Teams client-side policy block is cleared. Earlier, while the app was still sideloaded, the client logged isBotConversationBlocked … blockedByTenantPolicy: true, returning: true and disabled the compose box. After the app was approved and installed from the catalog, the same log line reads blockedByTenantPolicy: false, returning: false and sending works.
• Same tenant: the bot's Entra tenant and the Teams tenant are identical, so this is not a cross-tenant single-tenant limitation.
• Auth / app settings: validated implicitly by Direct Line succeeding (MicrosoftAppId, secret, MicrosoftAppType=SingleTenant, MicrosoftAppTenantId are shared across channels).
• Network path: no App Service access restriction and no Easy Auth interception — Azure Bot Service reaches the endpoint from outside and gets a 200.
• Teams channel is enabled and predates the failing test by an hour.
• Teams client cache cleared, app uninstalled and the stale 1:1 conversation removed, then reinstalled from the org catalog.

Question

What can cause the Microsoft Teams channel to silently drop activities — the Teams service accepting the message and assigning a server-side ID, but no activity ever reaching Azure Bot Service — while Direct Line works normally on the same bot registration?

Specifically:

1. Is there a provisioning step between the org catalog app and the Teams messaging fabric that can fail silently after an admin approval, and can it be forced to re-run other than by publishing a new manifest version?
2. Is there any place where a Teams-side delivery failure for a given bot App ID is surfaced — a log, a status on the channel, a diagnostic query?
3. Does ABSBotRequests log inbound Teams activities at all, or is Channel == "msteams" only populated for a subset of operations? I would like to know whether the absence of rows is meaningful evidence or not.