diff --git a/‎src/content/docs/factories/automations.mdx‎
Lines changed: 4 additions & 3 deletions b/‎src/content/docs/factories/automations.mdx‎
Lines changed: 4 additions & 3 deletions
diff --git a/‎src/content/docs/factories/connect-your-factory.mdx‎
Lines changed: 5 additions & 3 deletions b/‎src/content/docs/factories/connect-your-factory.mdx‎
Lines changed: 5 additions & 3 deletions
diff --git a/‎src/content/docs/factories/factory-as-code.mdx‎
Lines changed: 15 additions & 3 deletions b/‎src/content/docs/factories/factory-as-code.mdx‎
Lines changed: 15 additions & 3 deletions
diff --git a/‎src/content/docs/factories/integrations/github.mdx‎
Lines changed: 6 additions & 4 deletions b/‎src/content/docs/factories/integrations/github.mdx‎
Lines changed: 6 additions & 4 deletions
@@ -23,9 +23,9 @@ One event can match more than one automation, and each match starts its own run.
 
 ## Filters don't control access
 
-Filters decide when work starts, not what a running agent can reach. Access comes from what you authorize on each provider: the GitHub App installation, the GitLab bot's project membership, the Slack app's authorization, the Linear OAuth scope, or the Jira app installation. Tightening a filter never shrinks that access, and removing one never widens it. To change what an integration can reach, change what you authorize for that provider.
+Filters decide when work starts, not what a running agent can reach. Access comes from what you authorize on each provider: the GitHub App installation, the GitLab bot's project membership, the Slack app's authorization, the Microsoft Teams installation, the Linear OAuth scope, or the Jira app installation. Tightening a filter never shrinks that access, and removing one never widens it. To change what an integration can reach, change what you authorize for that provider.
 
-Filters are still your main control over who starts runs. On GitHub and GitLab, the event author doesn't need to be a Warp team member, so use author, member, and branch filters to decide whose activity starts work. Slack mentions and direct messages additionally require a Slack account linked to a member of the factory's Warp team. A custom webhook authenticates each delivery with the webhook's own secret or the sender's signature, so anyone holding that credential can start work; its filters only decide which deliveries do.
+Filters are still your main control over who starts runs. On GitHub and GitLab, the event author doesn't need to be a Warp team member, so use author, member, and branch filters to decide whose activity starts work. Slack mentions and direct messages additionally require a Slack account linked to an active member of the factory's Warp team. Microsoft Teams mentions require a Microsoft account linked to an active member of the factory's Warp workspace. A custom webhook authenticates each delivery with the webhook's own secret or the sender's signature, so anyone holding that credential can start work; its filters only decide which deliveries do.
 
 ## What each source can filter on
 
@@ -34,6 +34,7 @@ Every source filters on where the event happened: a repository, project, convers
 | Source | Filters |
 | --- | --- |
 | [Slack](/factories/integrations/slack/) | Conversations, authors or members, keywords, emoji, and reacted-message authors |
+| [Microsoft Teams](/factories/integrations/teams/) | Team, channels (standard picker; shared by channel ID), authors, and keywords |
 | [GitHub](/factories/integrations/github/) | Repository, branches, base branches, paths, labels, authors, assignees, mentioned users or teams, reviewers, review states, workflows, and conclusions |
 | [GitLab](/factories/integrations/gitlab/) | Project, actions, and base branch |
 | [Linear](/factories/integrations/linear/) | Teams, labels, project, workflow state, assignee, mentioned user, and, for comment events, a specific issue |
@@ -142,7 +143,7 @@ For exact matching semantics, limits, and validation rules, see [payload filter
 ## Related pages
 
 * [**Connect your factory**](/factories/connect-your-factory/) - Choose the sources that route work into the factory.
-* [Slack](/factories/integrations/slack/), [GitHub](/factories/integrations/github/), [GitLab](/factories/integrations/gitlab/), [Linear](/factories/integrations/linear/), and [Jira](/factories/integrations/jira/) integration guides - Per-source setup, events, and filter details.
+* [Slack](/factories/integrations/slack/), [Microsoft Teams](/factories/integrations/teams/), [GitHub](/factories/integrations/github/), [GitLab](/factories/integrations/gitlab/), [Linear](/factories/integrations/linear/), and [Jira](/factories/integrations/jira/) integration guides - Per-source setup, events, and filter details.
 * [**Custom webhooks**](/factories/webhooks/) - Start automations from any system that can POST JSON, with the setup flow and authentication modes.
 * [**Definitions as code**](/factories/factory-as-code/) - Manage automations, triggers, and filters as version-controlled files.
 * [**warp-factory-examples**](https://github.com/warpdotdev/warp-factory-examples) - Complete factory definitions with example automations and filters.
 
@@ -1,8 +1,8 @@
 ---
 title: Connect your factory
 description: >-
-  Route work into your factory from Slack, GitHub, GitLab, Linear, Jira, local
-  agents, direct runs, and schedules.
+  Route work into your factory from Slack, Microsoft Teams, GitHub, GitLab,
+  Linear, Jira, local agents, direct runs, and schedules.
 sidebar:
   label: "Connect your factory"
 ---
@@ -22,6 +22,7 @@ Once a source is connected, here's the concrete action that hands it work — ea
 | Source | Best for | Start work by | Continues in |
 | --- | --- | --- | --- |
 | [Slack](/factories/integrations/slack/) | Chat and support requests | [Mentioning the app in a channel, thread, or DM](/factories/integrations/slack/#start-and-continue-work-from-slack) | The Slack thread or DM |
+| [Microsoft Teams](/factories/integrations/teams/) | Chat in standard and shared channels | [Mentioning the Warp app in a configured channel](/factories/integrations/teams/#start-and-continue-work) | The Teams thread |
 | [GitHub](/factories/integrations/github/) | Issues, pull requests, reviews, and CI | [Adding the factory's label and mentioning **@warp**](/factories/integrations/github/#mention-the-factory) | The issue, pull request, or review thread |
 | [GitLab](/factories/integrations/gitlab/) | Merge request activity and bot mentions | [Mentioning the factory's bot in a merge request comment](/factories/integrations/gitlab/#mention-the-factory) | The merge request thread |
 | [Linear](/factories/integrations/linear/) | Planned issues | [Assigning the issue to the factory, or mentioning the Warp app in a comment](/factories/integrations/linear/#route-agent-sessions) | The Linear issue and its agent session |
@@ -59,11 +60,12 @@ Every request lands with the foreman agent, which turns it into a work item and
 
 When you create a factory through the setup wizard, Warp adds default automations for each tool you connect, so common requests work immediately:
 
-* **GitHub** - Starts work when the factory is mentioned or assigned, and follows up when pull requests close or merge, completing a linked tracker issue when it can. See the [GitHub integration guide](/factories/integrations/github/).
+* **GitHub** - Starts work from mentions and assignments, when the factory's label is applied to an issue or pull request, and when a review is submitted on a labeled pull request. It also follows up when labeled pull requests close or merge, completing a linked tracker issue when it can. See the [GitHub integration guide](/factories/integrations/github/).
 * **GitLab** - Starts work when someone mentions the factory's bot in a merge request comment. See the [GitLab integration guide](/factories/integrations/gitlab/).
 * **Jira** - Starts work when someone assigns or mentions Warp on a work item in one of the Jira projects you selected. See the [Jira integration guide](/factories/integrations/jira/).
 * **Linear** - Starts work when a new agent session arrives from one of the Linear teams you selected. See the [Linear integration guide](/factories/integrations/linear/).
 * **Slack** - Starts work from mentions and messages, as described in the [Slack integration guide](/factories/integrations/slack/).
+* **Microsoft Teams** - Starts work from app mentions in the channels you configured, including shared channels when the sender is in the same Microsoft 365 organization as the Warp app install and has linked that account to Warp. See the [Microsoft Teams integration guide](/factories/integrations/teams/).
 
 These defaults are starting points. Review each automation's filters, agent, and run settings, and adjust them to match your workflow. For automation files you can adapt, such as CI failure triage, a scheduled dependency audit, and Slack reaction intake, see [`06-common-automations`](https://github.com/warpdotdev/warp-factory-examples/tree/main/examples/06-common-automations) in the [warp-factory-examples](https://github.com/warpdotdev/warp-factory-examples) repository.
 
 
@@ -204,11 +204,12 @@ cloudProviders:
 
 ### `integrations`
 
-Optional. The integration providers attached to the factory. `type` accepts `slack`, `linear`, or `jira`. Use `linear.teamIds` or `jira.projectKeys` to limit the teams or projects available to the factory. Declare at most one issue tracker: `linear` and `jira` are mutually exclusive, and omitting a tracker is also valid. GitHub is not declared here; repository access comes from `repositories` and the connected GitHub App.
+Optional. The integration providers attached to the factory. `type` accepts `slack`, `microsoft-teams`, `linear`, or `jira`. Use `linear.teamIds` or `jira.projectKeys` to limit the teams or projects available to the factory. Declare at most one issue tracker: `linear` and `jira` are mutually exclusive, and omitting a tracker is also valid. GitHub is not declared here; repository access comes from `repositories` and the connected GitHub App.
 
 ```yaml
 integrations:
   - type: slack
+  - type: microsoft-teams
   - type: linear
     linear:
       teamIds:
@@ -226,6 +227,15 @@ integrations:
         - OPS
 ```
 
+For `microsoft-teams`, optional `autoRespondToThreadReplies` nests under the `microsoft-teams` key. Set it to `false` to require another mention for plain replies in an existing factory thread. Omit the key (or set `true`) to keep the default-on behavior:
+
+```yaml
+integrations:
+  - type: microsoft-teams
+    microsoft-teams:
+      autoRespondToThreadReplies: false
+```
+
 The legacy `providers` key is accepted when reading older definitions. It uses the same `gcp` and `aws` maps and nested YAML keys as `cloudProviders`. Use `cloudProviders`; when Warp rewrites the definition, it emits `cloudProviders`.
 
 ### `agentDefaults`
@@ -410,15 +420,16 @@ The providers and their events:
 * `linear` - `agent_session_created`, `comment_created`, `issue_assigned`, `issue_created`, `issue_labeled`, `issue_state_changed`
 * `jira` - `agent_session_created`, `issue_created`, `issue_labeled`, `status_changed`
 * `slack` - `app_mention`, `member_joined_channel`, `message_dm`, `message_im`, `message_mpim`, `message_posted`, `reaction_added`
+* `teams` - `app_mention`, `message_posted`
 * `schedule` - `cron_fired`
 * `webhook` - `received`
 * `factory` - `work_item_stage_changed`
 
-Slack, Linear, and Jira triggers require the matching [integration](/platform/integrations/) to be connected. GitHub triggers work through the factory's `repositories`, and GitLab triggers through the group connected to your workspace — see the [GitLab integration](/factories/integrations/gitlab/). `webhook` triggers listen to [custom webhooks](/factories/webhooks/) declared under [`webhooks/`](#webhooksnameyaml).
+Slack, Microsoft Teams, Linear, and Jira triggers require the matching factory integration to be connected — see the [Slack](/factories/integrations/slack/), [Microsoft Teams](/factories/integrations/teams/), [Linear](/factories/integrations/linear/), and [Jira](/factories/integrations/jira/) guides. GitHub triggers work through the factory's `repositories`, and GitLab triggers through the group connected to your workspace — see the [GitLab integration](/factories/integrations/gitlab/). `webhook` triggers listen to [custom webhooks](/factories/webhooks/) declared under [`webhooks/`](#webhooksnameyaml).
 
 ### `triggers[].filter`
 
-Optional. Narrows which events start runs. The keys a filter accepts depend on the provider and event: for example `repos`, `labels`, and `authors` for GitHub events, or `channels`, `users`, and `keywords` for Slack messages. Filter keys combine with AND, an omitted key matches everything, and each key takes a list that matches any of its values (or an `in`/`not_in` object to include or exclude). Slack and Linear filters take names (channels, users, teams, projects, states), and Warp resolves them to IDs when it applies the change.
+Optional. Narrows which events start runs. The keys a filter accepts depend on the provider and event: for example `repos`, `labels`, and `authors` for GitHub events, or `channels`, `users`, and `keywords` for Slack messages. Filter keys combine with AND, an omitted key matches everything, and each key takes a list that matches any of its values (or an `in`/`not_in` object to include or exclude). Slack and Linear filters take names (channels, users, teams, projects, states), and Warp resolves them to IDs when it applies the change. Microsoft Teams filters take Graph team UUIDs and Bot Framework channel IDs, and each Teams trigger must include exactly one team and at least one channel.
 
 A `webhook` trigger with the `received` event requires `webhook_ids` in its filter, a list of webhook UIDs (`in` only; the file name isn't accepted), and takes an optional `payload` pattern that mirrors the delivery's JSON body. See [payload filters for webhook triggers](/factories/automations/#payload-filters-for-webhook-triggers) for the pattern grammar.
 
@@ -431,6 +442,7 @@ The published trigger catalog currently uses these filter keys across its provid
 * Linear: `assignee_ids`, `creator_ids`, `issue_ids`, `issues`, `keywords`, `labels`, `mentioned_user_ids`, `project_ids`, `projects`, `state_ids`, `states`, `team_ids`, and `teams`.
 * Schedule: `schedule_ids` is server-managed and cannot be set in a factory definition.
 * Slack: `channel_ids`, `channels`, `emojis`, `itemUsers`, `item_user_ids`, `keywords`, `user_ids`, and `users`.
+* Teams: `channel_ids`, `keywords`, `team_ids`, and `user_ids`.
 * Webhook: `payload` and `webhook_ids`.
 
 Payload patterns also accept `exists`.
 
@@ -20,16 +20,18 @@ When you connect a factory to GitHub, repository activity starts work in your fa
 1. In the <a href={VARS.FACTORY_WEB_APP_URL}>{VARS.FACTORY_WEB_APP}</a>, click **+** next to **Factories** to open the setup wizard, then choose **I want to use repos from GitHub** under **Connect your code host**.
 2. Under **Select your repos**, choose the repositories to provide code and context for the factory.
 
-That's all the setup GitHub needs. A new factory arrives with two automations already switched on, so it responds to GitHub activity right away:
+That's all the setup GitHub needs. A new factory arrives with default automations already switched on, so it responds to GitHub activity right away:
 
-* **Mentions and assignments** - Start work by mentioning **@warp**. See [Mention the factory](#mention-the-factory) below.
-* **Pull request merges** - Close out work by merging a pull request with your factory's label. Any work items linked to the pull request move to their tracker's completed state. Closing without merging does nothing.
+* **Mentions and assignments** - Start work by mentioning **@warp** or assigning the factory. See [Mention the factory](#mention-the-factory) below.
+* **Pull request closed or merged** - Completes linked work when a pull request with your factory's label merges (which can move linked tracker issues to their completed state). An unmerged close is a no-op.
+* **Issue labeled** and **Pull request labeled** - Start work when the factory's label is applied to an issue or pull request.
+* **Pull request review submitted** - Start work when a review is submitted on a pull request that carries the factory's label.
 
 To confirm the connection works, mention **@warp** on a test issue and check that a work item starts in the factory's [dashboard](/factories/factory-dashboard/).
 
 ## Add a custom automation
 
-The defaults cover mentions, assignments, and pull request completion. To start work from any other GitHub activity, such as a failed CI run or a review request, add an automation with a GitHub trigger for that event, then narrow it with the filters below. To learn how to edit those filters, see [Automations](/factories/automations/#edit-filters-on-an-automation).
+The defaults cover mentions, assignments, label routing, review submissions, and pull request completion. To start work from any other GitHub activity, such as a failed CI run or a review request, add an automation with a GitHub trigger for that event, then narrow it with the filters below. To learn how to edit those filters, see [Automations](/factories/automations/#edit-filters-on-an-automation).
 
 The CI failure triage automation in [`06-common-automations`](https://github.com/warpdotdev/warp-factory-examples/tree/main/examples/06-common-automations) in the [warp-factory-examples](https://github.com/warpdotdev/warp-factory-examples) repository starts work when a workflow run fails on the default branch: