OpenClaw Microsoft Teams access control
Config writes, the single-account rule, DM pairing with stable object IDs, group policy and group allowlists with conversation IDs, team and channel allowlists, why the groupId query parameter is not the team ID, and the limits of private channels
Teams access control is short on options and long on identifiers: one account, four DM policies, a group policy, and allowlists that must hold the right kind of ID. The ID part is where installs go wrong, because the obvious value in a Teams URL is the wrong one. Here are the policies, the allowlists, the URL gotcha, and what private channels cannot do.
DMs and groups
- Teams can write config updates triggered by the config set and unset commands by default, which requires the config command to be enabled, and the config-writes key set to false disables them; the channel has one account per configuration, so policies sit directly under the channel block and an accounts map is not supported.
- The DM policy defaults to pairing, where unknown senders are ignored until approved, the DM allowlist should use stable AAD object IDs or static sender access groups, UPN and display-name matching is not to be relied on because both can change and direct name matching is disabled by default behind the dangerous switch, and the wizard can resolve names to IDs through Graph when credentials allow.
- The group policy defaults to allowlist, blocked until you add a group allowlist, must be set explicitly to choose another policy because the root schema default takes precedence over the channel defaults, and takes open to allow any member, still mention-gated, or disabled to block every channel; the group allowlist controls which senders, static access groups or group and channel conversation IDs can trigger in group chats and channels, falls back to the DM allowlist, accepts the three thread ID forms with exact casing preserved, ignores message-ID suffixes, and never grants personal-DM access.
- Team and channel allowlists scope replies by listing teams and channels under the teams map keyed by stable conversation IDs from Teams links rather than display names; with an allowlist policy and a teams allowlist present only the listed teams and channels are accepted, mention-gated, the group allowlist authorises senders rather than delegated Graph reads of other channels, a config that only sets the group allowlist should keep the allowlist policy and add the target under the team's channels, an open policy allows broader delegated reads but admits any group sender, direct-operator reads and current-conversation reads need no extra route, the wizard stores team and channel entries, and at startup names are resolved to IDs and logged, with unresolved names kept but ignored for routing unless the dangerous switch is on.
Conversation IDs never grant personal-DM access.
The URL gotcha
The groupId query parameter in Teams URLs is not the team ID used for configuration. The IDs come from the URL path: for a team URL the segment after the team path component, URL-decoded into the thread form, and for a channel URL the segment after the channel path component, again decoded. The team key is that decoded team segment, which older tenants may show with a skype thread suffix that is also valid, the channel key is the decoded channel segment, and the groupId parameter is ignored for routing because it is the Microsoft Entra group ID rather than the Bot Framework conversation ID that incoming Teams activities carry.
Private channels
- Bots have limited support in private channels: installation is limited, real-time webhook messages may not work, resource-specific permissions may behave differently, mentions work only if the bot is accessible, and Graph history works with the right permissions, whereas standard channels support all of them.
- The first two workarounds are to use standard channels for bot interactions and to use DMs, since users can always message the bot directly.
- The third is Graph history for historical access, which requires the channel message read-all permission and admin consent.
OpenClaw on Microsoft Teams is the channel post these rules belong to, and OpenClaw Microsoft Teams message behaviour where an admitted message is routed and threaded.
Three kinds of ID
An Entra object ID identifies a person, a thread-form conversation ID identifies a team or channel, and an Entra group ID identifies neither for routing purposes, which is why the docs spend a section on which URL segment to copy. OpenClaw access groups explains the access groups the allowlists can reference, and OpenClaw Slack access control the equivalent rules on Slack, where channel keys must be IDs for the same reason.
On Diali
Microsoft Teams is not among the channels Diali connects today: WhatsApp, Telegram, Discord, Slack, Mattermost, Matrix, SMS and voice. Hosted OpenClaw on Diali is the assistant, and Connect your first channel in five minutes shows the channels you can connect in five minutes.
- One account; object IDs for people, thread IDs for channels.
- The groupId parameter is never the team ID.
- Private channels may not deliver webhooks; use standard ones or DMs.
Stop reading about it, build one
Set up an agent, pick a channel, and have it working inside the app you already keep open.
