Power Platform Community Forum Thread Details

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 operation: Succeeded
- Channel state: Synchronized
- Agent Registry: Available
- Authentication: Integrated
- Tool credentials: Maker-provided
- MCP/custom connector runtime: working
- Controlled tool test in Studio: HTTP 200 and valid result
- Microsoft 365 Copilot routing: working

Failure specific to Teams:

- Messages sent in Teams web and Teams desktop are visibly delivered in the agent personal chat.
- The agent never replies.
- Copilot Studio activity/monitor data contains Microsoft 365 Copilot sessions, but no Teams session for the corresponding timestamps.
- Teams Admin Center Manage apps returns no matching item by agent name or exact app ID, although the agent is Available in Microsoft 365 Agent Registry.
- Re-publishing, OAuth reconnects, MCP restarts, and connector changes have intentionally not been used because the same published agent and connection work in M365 Copilot and Studio.

Current classification:

FAIL — Teams inbound activity is not reaching the Copilot Studio agent.

Questions:

1. Have you seen an agent work in M365 Copilot but receive no personal-chat activities from Teams?
2. Can Agent Registry show Available while Teams Admin Center Manage apps has no matching row?
3. Is there a known Unified App Management synchronization issue for Copilot Studio agents?
4. Is a separate Teams app catalog deployment or approval required even when the Copilot Studio Teams channel shows Synchronized?
5. Which logs or admin surface can prove whether Teams attempted to route the inbound activity to the agent?
6. Are there known manifest, personal scope, app-centric management, or conversation-binding issues that produce this exact split?

We are looking for confirmed production experience or a documented workaround. We can provide redacted screenshots and timestamps, but no tokens or tenant secrets.

Hey @MP-23071301-0

Seen this exact split. The tell in your evidence is "no Teams session in the monitor for those timestamps" , that means the inbound activity never reached the bot runtime, so it's a routing/catalog problem at the Teams distribution layer, not agent config or auth. That's why republish/OAuth/reconnect fixes don't apply here.

TBH I've seen this cut both ways in production. Some Studio agents behave better in Teams than in the M365 web interface, others the reverse, and it extends to surface behavior too: suggested/starter prompts sometimes render in Teams but not M365, and vice versa. That inconsistency is the giveaway that these are two independent pipelines with their own catalogs and rendering, not one agent with one config. Whenever the two disagree, I stop looking at the agent and start looking at which surface's catalog/policy path is broken.

On your Q2/Q3 specifically: Agent Registry (MAC) can absolutely show Available while TAC Manage apps has no row, because they're separate catalogs. Under unified agent and app management they're supposed to stay in sync, changes to agent app status/availability in one admin center propagate to the other , but on a tenant that isn't (fully) unified, the two run independently, which produces exactly your Registry-present / TAC-absent state with no bug required. Microsoft's own doc on managing the Agent Registry describes this MAC & TAC sync as conditional on the tenant being unified: https://learn.microsoft.com/en-us/microsoft-365/admin/manage/agent-registry

Practical next steps that don't risk your working M365 path (no republish):

1. Have a Global admin check TAC / Teams apps / Manage apps for the "Move to unified app management" banner , if it's there, the tenant isn't unified and that's your split.
2. Search Manage apps under both "Custom apps" and "Built with Power Platform" filters, plus exact app ID , Power Platform-published agents get categorized separately from custom uploads.
3. Confirm org-wide app settings allow Power Platform apps in Teams, and check the app permission/setup policy assigned to the affected user.
4. If Application Insights is wired to the bot resource, confirm zero inbound at the messaging endpoint, that turns "no monitor session" from inference into proof the activity never routed.

One last thing worth keeping in the back of your mind: Microsoft is shipping a lot right now (which is Great), Frontier preview features, the modern Copilot Studio authoring canvas, and unified app management are all landing at the same time — and sometimes these surfaces just fall out of step for a release or two. If Frontier is enabled on your tenant, or your agents are split across the old and new builder, that's worth ruling out as a contributor to the surface-to-surface inconsistency. For your specific "no inbound / no TAC row" symptom I'd still bet on the catalog/unification path above, but the general churn is real and it does produce these one-surface-but-not-the-other quirks.