How to Connect OpenClaw to Microsoft Teams

Microsoft Teams is one of the more structured OpenClaw channel setups because you are bridging the Gateway to Microsoft's bot stack. The good news is that the official docs keep the path concrete: Teams is a bundled plugin, the preview Teams CLI can handle bot registration and manifest creation, and OpenClaw only needs the resulting app credentials plus the webhook settings.

When this is the right move

Use this when the people who need the agent already live in Teams and you want replies to stay in DMs, group chats, or channels instead of bouncing through another chat surface. It is also the right move when you want Graph-backed identity controls and clear per-team routing rather than informal name matching.

The practical workflow

1. Install the preview Teams CLI, sign in, and confirm the tenant is visible with teams status before you touch OpenClaw config.
2. Start a tunnel for the bot webhook. The docs show devtunnels on port 3978 because Teams cannot call your localhost directly.
3. Create the Teams app with the CLI so it generates the app registration, client secret, and manifest in one flow.
4. Paste the returned CLIENT_ID, CLIENT_SECRET, and TENANT_ID into channels.msteams, then restart the Gateway.
5. Install the app in Teams, run teams app doctor <teamsAppId>, and only then widen DM or group access rules.

Grounded command or config pattern

After teams app create returns your credentials, the official docs show this minimal OpenClaw channel block.

{
  channels: {
    msteams: {
      enabled: true,
      appId: "<CLIENT_ID>",
      appPassword: "<CLIENT_SECRET>",
      tenantId: "<TENANT_ID>",
      webhook: { port: 3978, path: "/api/messages" },
    },
  },
}

The same docs pair that with a tunnel endpoint such as https://<tunnel-id>.devtunnels.ms/api/messages. They also note that DMs are pairing-gated by default and group chats stay blocked until you set groupAllowFrom or intentionally change groupPolicy.

Operator notes

Teams support includes DMs, text, attachments, polls through Adaptive Cards, and explicit file uploads. The docs are very clear about access control: keep allowFrom on stable AAD object IDs when possible, leave dangerous name matching off unless you truly need it, and remember that channel or team allowlists can narrow where the bot is even allowed to wake up.

Rollout approach

For connecting OpenClaw to Microsoft Teams, I would keep the first pass narrow: one tenant, one bot app, one approved DM sender, and one test channel with mention-gated replies. Teams gives you a lot of surface area quickly, so a small rehearsal is better than turning on every team and discovering the routing mistake in production.

Common mistake

The common mistake is treating the command or config key as the whole feature. The command starts the workflow, but the surrounding state is what keeps it reliable: config validation, auth, pairing, permissions, logs, and one small verification step. If those pieces are skipped, the next failure looks random even when OpenClaw is behaving exactly as configured.

Maintenance rhythm

Once this is working, write down the exact command, config path, or approval decision you used. Future you will not remember the tiny detail that made the setup safe. A short note in the workspace or runbook is cheaper than rediscovering the same behavior during an outage, especially after updates or host changes.

Safety checks

Do not open Teams groups broadly on day one. Leave groupPolicy on allowlist, add only the senders or channels you actually trust, and treat app secrets and tunnel URLs like real production credentials. If you later need group file sending, add the required SharePoint and Graph permissions intentionally rather than assuming plain text bot access covers it.

How to verify it worked

Run teams app doctor <teamsAppId>, send a DM from an approved sender, then try a mention in one authorized group or channel. If the DM works but the group does not, check the group allowlist and mention rules before changing any model or session settings. openclaw status is also a good final sanity check after restart.

If you want the operator version with sharper checklists, safer defaults, and fewer “why is this broken?” afternoons, The OpenClaw Playbook is the shortcut I would hand to a serious OpenClaw owner.