App Validation failing for no clear reason
We're trying to get our (very simple) Teams App listed on the app store, but during the App Validation we keep getting the same error: "Unable to upload the manifest.zip file in MS Teams." as seen below: Downloading the report doesn't give any more information, it only lists the only successful validation step ("BotID should be registered") and the error doesn't appear there. I've validated the manifest.json file against the schema, tried reuploading the same manifest to a different org (creating a new app and bot) - validation fails there too. Does anyone have any pointers? Here is my (anonymized) manifest file: { "$schema": "https://developer.microsoft.com/en-us/json-schemas/teams/v1.19/MicrosoftTeams.schema.json", "manifestVersion": "1.19", "version": "1.1.1", "id": "[redacted]", "developer": { "name": "[redacted]", "websiteUrl": "https://www.[redacted].com", "privacyUrl": "[redacted]", "termsOfUseUrl": "[redacted]" }, "icons": { "color": "color.png", "outline": "outline.png" }, "name": { "short": "[redacted]", "full": "[redacted]" }, "description": { "short": "[redacted]", "full": "[redacted]" }, "accentColor": "#4A3AFF", "bots": [ { "botId": "[redacted]", "scopes": ["personal"], "supportsFiles": false, "isNotificationOnly": false, "commandLists": [ { "scopes": ["personal"], "commands": [ { "title": "help", "description": "Show what this bot does and how to connect your account" }, { "title": "connect", "description": "Get a fresh link to (re-)connect your account" } ] } ] } ], "staticTabs": [ { "entityId": "conversations", "scopes": ["personal"] }, { "entityId": "about", "scopes": ["personal"] } ], "permissions": ["identity", "messageTeamMembers"], "validDomains": ["app.[redacted].com", "auth.[redacted].com"] }
TeamsTab.ReadWriteSelfForTeam: deleting a tab fails with 400 "appId cannot be null or whitespace"
We have a published Teams app that pins a configurable tab into a team channel via Microsoft Graph and removes it again when the user uninstalls our app from that channel. Creating the tab works. Deleting it always fails with a 400 that looks like an unhandled null-argument exception inside the Graph Teams service rather than a permission problem. I reported this in October 2025 as https://github.com/MicrosoftDocs/msteams-docs/issues/13432, but that is a documentation repository and the issue has had no response, so I am reposting here, as we can still reproduce the issue. We're using a delegated token for the operation. The only tab-related scopes are `TeamsTab.Read.All` (read-only) and `TeamsTab.ReadWriteSelfForTeam`. According to the docs (https://learn.microsoft.com/en-us/graph/api/channel-delete-tabs), `TeamsTab.ReadWriteSelfForTeam` is the **least privileged** delegated permission for the delete, so the token should be ok. What works Creating the tab, with the same delegated user token: POST https://graph.microsoft.com/v1.0/teams/«teamId»/channels/«channelId»/tabs Content-Type: application/json { "displayName": "«AppName»", "email address removed for privacy reasons": "https://graph.microsoft.com/v1.0/appCatalogs/teamsApps/«teamsAppId»", "configuration": { "entityId": "«entityId»", "contentUrl": "https://«ourhost»/teams/tabs/channel/«entityId»", "websiteUrl": "https://«ourhost»/app/tickets?channel=«entityId»", "removeUrl": "https://«ourhost»/teams/remove-tab/«entityId»" } } → `201 Created`. The tab appears in the channel and renders correctly. Listing the tabs afterwards also works and returns our tab together with its `id`: GET https://graph.microsoft.com/v1.0/teams/«teamId»/channels/«channelId»/tabs?$expand=teamsApp Works as well and lists our tab. Might be served by the TeamsTab.Read.All permission. What fails DELETE https://graph.microsoft.com/v1.0/teams/«teamId»/channels/«channelId»/tabs/«tabId» → `400 Bad Request` { "error":{ "code":"BadRequest", "message":"appId cannot be null or whitespace. (Parameter 'appId')", "innerError":{ "date":"2026-07-27T13:45:31", "request-id":"f930c847-0b48-4a46-b17e-f0ee10ff8177", "client-request-id":"f930c847-0b48-4a46-b17e-f0ee10ff8177" } } } (leaving in the error details, maybe that helps diagnosing the issue) appID is not even part of the request, it's probably resolved against the TeamsTab.ReadWriteSelfForTeam permission on your side. Let me know if you need any more details.
CS agent OK in M365 Copilot; Teams chat silent / no Studio session
We are troubleshooting a Copilot Studio agent that works correctly in Microsoft 365 Copilot and in the Copilot Studio test surface, but does not receive inbound activities from Microsoft Teams personal chat. Environment and evidence: - Agent: Copilot Studio agent (custom business assistant) - Copilot Studio agent ID: 88901b10-… (truncated) - Teams/Entra app ID: 7e4a53cc-… (truncated) - Manifest version: 1.0.8 - Channel configuration: Microsoft 365 Copilot + Microsoft Teams - Publish: Succeeded / Channel state: Synchronized - Agent Registry: Available - Authentication: Integrated / Tool credentials: Maker-provided - MCP/custom connector runtime: working (Studio tool test HTTP 200) - Microsoft 365 Copilot routing: working Failure specific to Teams: - Messages in Teams web and desktop appear delivered in the agent personal chat - Agent never replies - Studio monitor has M365 Copilot sessions, but no Teams session for those timestamps - Teams Admin Center Manage apps returns 0 results by name or exact app ID despite Agent Registry Available - Intentionally not republishing / reconnecting OAuth / rewiring connectors because M365 Copilot path proves the same agent+connection works Classification: FAIL — Teams inbound activity is not reaching the Copilot Studio agent. Questions focused on Teams delivery: 1. Why would Teams personal 1:1 messages never create a Studio conversation while M365 Copilot does? 2. Is a missing TAC Manage apps row expected under Unified App Management when Registry shows Available? 3. Known gaps: Agent Registry Available + channel Synchronized, but Teams client chat bound to a non-runtime endpoint? 4. Best diagnostic if Monitor shows 0 Teams sessions after a confirmed client send? Looking for production experience / documented workaround. Redacted evidence available; no tokens/secrets.
[Adaptive Card] Issue with CodeBlock line numbers and more
I have a simple adaptive card containing a code block with multiline SQL in it: from botbuilder.core import CardFactory, MessageFactory, TurnContext async def send_sql_card(context: TurnContext): SQL_QUERY = """SELECT order_date, customer_id, SUM(quantity * unit_price) AS revenue FROM catalog.sales.order_items WHERE order_date >= DATE '2026-01-01' AND order_date < DATE '2026-06-01' GROUP BY order_date, customer_id """ activity = MessageFactory.attachment( attachment=CardFactory.adaptive_card( { "type": "AdaptiveCard", "$schema": "http://adaptivecards.io/schemas/adaptive-card.json", "version": "1.6", "msteams": {"width": "full"}, "body": [ { "type": "CodeBlock", "codeSnippet": SQL_QUERY, "language": "sql", }, ], } ) ) await context.send_activity(activity) This worked fine until maybe a few weeks ago. Now, there are two issues: Line numbers appear twice: Not all lines are being shown: It says "Expand (11 lines)", but it only shows 9. This happens on Teams Desktop - it looks fine on the web version.Migrating Teams Calling Bot (EchoBot) from VMSS to Windows Containers / ACI?
Hi everyone, I have built a Microsoft Teams Calling Bot using Application-Hosted Media based on the official C# EchoBot sample: https://github.com/microsoftgraph/microsoft-graph-comms-samples/tree/master/Samples/PublicSamples/EchoBot Currently, our signaling logic is fully serverless and runs efficiently on Azure Functions. However, the actual media processing (using the C# Calling SDK which relies on native Windows media binaries) is deployed on VMSS with Windows Server, just like the repository's default deployment guide suggests. Running these Windows VMs continuously is becoming extremely expensive, and we are looking for a cheaper, modern, or "on-demand" alternative to handle the media pipeline. Since raw audio processing strictly requires these native Windows-based Media binaries, I would like to ask the community: 1. Windows Containers (ACI / AKS): Has anyone successfully run this C# EchoBot/Media SDK inside Windows Containers (such as Azure Container Instances or AKS)? If so, how do you handle the public IP and port-binding requirements for the media sockets (since the platform needs direct public connectivity for UDP/TCP traffic)? 2. On-Demand Provisioning: Are there any known architectures or best practices for spinning up the media processor only when a call starts (e.g., triggering an ACI instance via the Azure Function signaling bot) and tearing it down afterwards to keep costs near zero when idle? 3. Alternative Approaches: If you have solved this high-infrastructure cost problem for a real-time raw audio bot in production, what architecture did you end up using? Any documentation, GitHub references, or architectural advice would be highly appreciated! Thanks!Can same-tenant meeting bots be routed through lobby approval like external bots?
Hello! As far as I understand, external third-party meeting bots are now detected by Teams and routed to the lobby via RequireApprovalWhenDetected; the organizer must admit them. Same-tenant bots bypass this entirely. Is there currently a way to apply lobby approval to same-tenant bots so it does not appear as a participant until explicitly let into the room? If not, is this on the roadmap? Could for example be a per-app flag on the Entra app registration or a Graph API parameter on the join call. All the best, HaraldRegarding Teams Meeting Media Transport Behavior in VDI Optimization Scenario
Hello Microsoft Teams Engineering Team, I am currently working on a Browser Content Redirection / media offload implementation for a VDI environment, where WebRTC media transport is handled through a local native component while the Teams application continues running inside the virtual desktop session. While testing, I observed that: 1:1 calls successfully receive audio and video media But in meetings auido / video RTP is never forwarded despite successful ICE, DTLS, and SRTP establishment DTLS ApplicationData traffic is present during meetings, suggesting DataChannel/SCTP activity Based on transport-level observations, it appears that Teams meetings may rely on SCTP/DataChannel communication for SFU video subscription management, while 1:1 calls do not require the same subscription flow. I wanted to ask whether: Teams meeting video forwarding depends on active bidirectional SCTP/DataChannel connectivity Meeting video subscriptions are expected to be coordinated over the WebRTC data channel/control plane Split ownership of media transport and control-plane transport could affect expected Teams meeting behavior in VDI optimization scenarios Thank you for your time and guidance. Best regards,RajdevAdaptive Cards in Teams channel messages: fixed narrow width — request for width control
Hi Teams Platform team, We post structured status reports as Adaptive Cards into a Teams channel. The card consistently renders at a fixed width of 448 px on a 1080p display at 100% scaling with a maximized Teams desktop client — well below the available channel message stream width. Wide multi-column tables get truncated or wrapped, which significantly hurts readability. What we've tried No card-level `width` property exists in the Adaptive Cards schema. `msteams.width: "Full"` is documented to apply only to Stageview / task module / tab — silently ignored in channel messages (tested). Same payload via three delivery paths — Incoming Webhook, Logic App "Post adaptive card in chat or channel", and Microsoft Graph `POST /teams/{id}/channels/{id}/messages` — all render at the same narrow fixed width. The constraint is in the Teams channel-message renderer, not in any delivery layer. Minimal repro payload (7-column results table; all field names and values replaced with generic placeholders): { "type": "message", "attachments": [ { "contentType": "application/vnd.microsoft.card.adaptive", "content": { "$schema": "https://adaptivecards.io/schemas/adaptive-card.json", "type": "AdaptiveCard", "version": "1.5", "msteams": { "width": "Full" }, "body": [ { "type": "TextBlock", "text": "Pipeline Report — run-001", "weight": "Bolder", "size": "Medium" }, { "type": "Table", "gridStyle": "accent", "firstRowAsHeaders": true, "columns": [ { "width": 2 }, { "width": 1 }, { "width": 2 }, { "width": 1 }, { "width": 2 }, { "width": 1 }, { "width": 1 } ], "rows": [ { "type": "TableRow", "cells": [ { "type": "TableCell", "items": [{ "type": "TextBlock", "text": "Col-1", "weight": "Bolder", "size": "Small" }] }, { "type": "TableCell", "items": [{ "type": "TextBlock", "text": "Col-2", "weight": "Bolder", "size": "Small" }] }, { "type": "TableCell", "items": [{ "type": "TextBlock", "text": "Col-3", "weight": "Bolder", "size": "Small" }] }, { "type": "TableCell", "items": [{ "type": "TextBlock", "text": "Δ Col-3", "weight": "Bolder", "size": "Small" }] }, { "type": "TableCell", "items": [{ "type": "TextBlock", "text": "Col-4", "weight": "Bolder", "size": "Small" }] }, { "type": "TableCell", "items": [{ "type": "TextBlock", "text": "Δ Col-4", "weight": "Bolder", "size": "Small" }] }, { "type": "TableCell", "items": [{ "type": "TextBlock", "text": "Status", "weight": "Bolder", "size": "Small" }] } ] }, { "type": "TableRow", "cells": [ { "type": "TableCell", "items": [{ "type": "TextBlock", "text": "item-a", "size": "Small" }] }, { "type": "TableCell", "items": [{ "type": "TextBlock", "text": "mode-x", "size": "Small" }] }, { "type": "TableCell", "items": [{ "type": "TextBlock", "text": "0.000/0.000","size": "Small" }] }, { "type": "TableCell", "items": [{ "type": "TextBlock", "text": "+0.00%", "size": "Small", "color": "Good" }] }, { "type": "TableCell", "items": [{ "type": "TextBlock", "text": "0.000/0.000","size": "Small" }] }, { "type": "TableCell", "items": [{ "type": "TextBlock", "text": "-0.00%", "size": "Small", "color": "Attention" }] }, { "type": "TableCell", "items": [{ "type": "TextBlock", "text": "✅ Pass", "size": "Small" }] } ] } ] } ] } } ] } `msteams.width: "Full"` is present but has no visible effect in the channel message context. Feature request Either of: Honor `msteams.width: "Full"` in channel-message context (not just Stageview/task module/tab), OR Add a card-level property (e.g. `msteams.channelWidth: "Full" | "Default"`) explicitly scoped to channel messages. Is this a known limitation with an existing tracking item, or should we also file it on the M365 Feedback Portal for upvotes? Thanks!
