Microsoft Teams Office 365 Connectors Retirement: Move Webhooks to Owned, Governed Workflows

Office 365 connectors in Microsoft Teams, including connector-based incoming webhooks, have been retired, and any alerting pipeline that still posts to an old webhook URL is now silently failing or has been rebuilt in a hurry without governance. Microsoft moved the deadline several times between 2024 and 2026 before the final shutdown in May 2026. The replacement, Workflows webhooks built on Power Automate, changes who owns the integration, where the credential lives and which policies apply to it. This guide covers the official timeline, how to find what was affected, how to migrate or clean up safely, and how to govern the new flows. It is written for Microsoft 365 administrators, platform engineers and security teams who own Teams notifications from CI/CD, monitoring and SaaS tools. For Teams security as a whole, see the Microsoft Teams Security Guide.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• The connectors are gone. Microsoft's final update set the deprecation rollout for 18 to 22 May 2026, after which Office 365 connectors no longer function.
• A webhook URL is a bearer credential. Anyone holding a Workflows webhook URL can post into the target channel or chat, so it belongs in a secrets store, not in pipeline YAML or a wiki page.
• Ownership moved from the channel to a person. Workflows are tied to their owners, not to a team or channel, so a leaver can break alerting unless a co-owner or service account owns the flow.
• Power Platform data policies now apply. The new flows sit in a Power Platform environment, so connector classification, environment strategy and orphan flow reviews become part of Teams governance.
• Parity is close but not complete. MessageCard payloads render, but interactive HTTP POST buttons do not work and custom bot names and icons are not available, so test every card type before cutover.

What is changing and why

Teams historically offered three integration patterns that look similar but behave differently. Office 365 connectors (connectors for Microsoft 365 Groups) let a channel subscribe to notifications from a web service, configured at channel level and installed at team level. The Incoming Webhook connector exposed an HTTPS endpoint that accepted JSON and inserted the message into a channel. Outgoing webhooks run the other way, sending channel messages to an external service that must respond within 10 seconds, and are not part of this retirement.

Microsoft retired the first two in favour of the Workflows app in Teams, which builds Power Automate flows from templates. A Workflows webhook uses the trigger When a Teams webhook request is received and then posts a card to a channel or chat. Microsoft Learn now states that Office 365 connectors in Teams, including connector-based incoming webhooks, were retired in May 2026.

Official timeline and current status

The Microsoft 365 Developer Blog announcement was updated repeatedly. The dates below are as stated in that post and on Microsoft Learn, checked on 8 November 2026. Earlier dates were superseded, which is why many organisations treated the deadline as soft and were caught out by the final rollout.

Status as of November 2026: retired. Microsoft Learn describes the connectors as retired in May 2026. There is no published extension mechanism, so any remaining connector configuration should be treated as dead and cleaned up, not revived.

Who and what is affected

• CI/CD and DevOps pipelines: build, deployment and release notifications from Azure DevOps, GitHub Actions, Jenkins and similar tools that used an incoming webhook URL stored as a pipeline variable or secret.
• Monitoring and incident tooling: uptime monitors, SIEM and SOAR alert routing, cloud cost alerts and on-call tools that posted alert cards into operations channels. A silent failure here removes a detection path without anyone noticing.
• SaaS-native connectors: third-party services configured from the Teams connectors gallery, plus RSS and other polling connectors. These need rebuilding as Workflows or replacing with the vendor's own Teams app.
• Interactive cards: approval buttons or acknowledge actions built on MessageCard HTTP POST actions. These render but no longer act; they need Adaptive Cards with a workflow that handles responses, or a bot.
• Government clouds: Microsoft Learn notes webhooks and connectors were available in GCC but not in GCC High, DoD or Teams operated by 21Vianet, apart from manually uploaded Incoming Webhook connectors in GCC High. Check your cloud before assuming the commercial path applies.
• Identity owners: each new flow creates a new owner relationship and, often, a connection under a user account. That is a new non-human integration with a human dependency.

Finding affected systems and identities

Inventory has two sides: the senders that still hold old URLs, and the new flows that replaced them. Start with senders, because a retired URL fails on the sender side and the error is often swallowed.

1. Search code and configuration for old endpoints. Scan repositories, pipeline variables, infrastructure as code, container environment files and secrets stores for Teams webhook hostnames and paths (connector URLs contained webhook.office.com or the older outlook.office.com/webhook form). Use your secret scanning tool's custom patterns so the same check runs on every new commit.
2. Check sender logs for failures. Look for repeated HTTP 4xx responses from Teams endpoints in monitoring tools, CI logs and SIEM forwarders since mid May 2026. Each failing sender is an alert path that went dark.
3. List remaining connector configurations. In each team, Manage channel then Connectors shows what was configured. Record the channel, configurer and source service, then remove the entries once the replacement is proven.
4. Inventory the new flows. In the Power Platform admin center, open the environment (usually the default environment for Teams Workflows), then Resources and Flows. Admins can also use Get-AdminFlow -EnvironmentName <env> to list flows and Get-AdminFlowOwnerRole to see owners and roles. Filter for flows using the Teams webhook trigger.
5. Find orphan flows. Flows with no entry in the Owners column, or whose owners no longer exist in Entra ID, are orphans. Microsoft's troubleshooting article gives a PowerShell pattern that loops over flows, reads owner roles and checks each principal still exists.
6. Map each flow to an accountable owner and a sender. Record flow name, environment, target channel or chat, template used (and so who may trigger it), owner, co-owners, connection account, sender system and where the URL is stored.

This register is the integration inventory that NIST CSF 2.0 ID.AM-02 and CIS Controls v8.1 Control 2 expect, applied to low-code integrations. See the Power Automate connections security guide for connection-level controls.

Migration options

Choosing: small organisations with a handful of alert channels will usually be fine with Workflows templates owned by a shared, licensed service account. Large organisations with dozens of senders should treat this as an integration platform decision: a notification bot or a central alerting flow gives one owner, one identity and one place to rotate, instead of hundreds of person-owned flows.

Securing the new flows

• Template scope: the Workflows templates differ by authentication type: alerts from anyone, from specific people, or from people in your organisation. Prefer the narrowest template that the sender can satisfy; external systems usually need the "anyone" variant, which makes URL secrecy the only control.
• URL handling: store the URL in a secrets manager or pipeline secret, never in plain configuration, and rotate by deleting and recreating the flow if it leaks. See the Webhook Secrets Security Guide.
• Ownership: add at least one co-owner, or create business-critical flows under a dedicated, licensed account with documented ownership, so a leaver does not break alerting.
• Data policies: Power Platform data policies group connectors as Business, Non-business or Blocked, and connectors in different groups cannot share data in one flow. Set the default group to Non-business so new connectors are reviewed, and decide whether the default environment should allow makers to combine Teams with external connectors at all.
• Content: do not post secrets, tokens or customer data in alert cards. Teams messages are retained and searchable, and a card is the easiest place for a credential to leak.

For wider low-code governance, see the Low-Code and No-Code Application Security Guide.

Testing and rollback

1. Build in parallel: create the Workflows webhook alongside the existing integration and point a test sender at it, using a test channel first.
2. Test each payload type: send every card the sender produces. Confirm MessageCard rendering, check that no workflow relies on HTTP POST action buttons, and confirm payloads stay under 28 KB.
3. Test failure behaviour: send a burst above four requests per second and confirm the sender retries with exponential backoff on HTTP 429 instead of dropping alerts.
4. Test ownership resilience: confirm a co-owner can edit and re-enable the flow without the creator.
5. Cut over sender by sender: swap the stored URL in the secrets store, watch the first real alerts arrive, then remove the old connector entry and its stored URL.
6. Rollback: the old connectors cannot be restored after May 2026, so rollback means turning the flow off and back on, restoring a previous flow version, or routing alerts temporarily to email or the on-call tool. Keep that fallback route documented for each critical alert.

Risks of doing nothing

• Silent detection loss: security and operations alerts that relied on a connector stopped arriving after 22 May 2026. Absence of alerts looks like calm.
• Stale credentials in code: old URLs remain in repositories and pipeline history. They no longer post, but they teach engineers that webhook URLs are safe to commit, and the habit carries into the new URLs.
• Shadow migrations: users rebuilt alerts under personal accounts in the default environment, often with the "anyone" template, creating unowned, unreviewed integrations.
• Orphan flows: when the creator leaves, the flow and its connection can fail, or keep running with nobody accountable for it.
• Spoofed messages: a leaked Workflows URL lets an outsider post convincing cards into a trusted channel, a ready-made phishing channel. Teams is already abused for social engineering; see the Email Bombing and Help Desk Impersonation over Teams Guide.

Framework mapping

Practitioner checklist

• Scan repositories, pipelines and secrets stores for old Teams connector URLs and remove them after cutover.
• Review sender logs for Teams endpoint failures since 18 May 2026 and restore every critical alert path.
• Export all flows using the Teams webhook trigger with their owners, co-owners, template type and target channel.
• Give every business-critical flow a co-owner or a dedicated licensed owner account.
• Store Workflows webhook URLs in a secrets manager and add a custom secret scanning pattern for them.
• Set the data policy default group to Non-business and review which connectors may combine with Teams in the default environment.
• Replace MessageCard action buttons with Adaptive Cards and a response-handling flow, or a bot.
• Run a monthly orphan flow review and a quarterly check that each alert still has a consumer.

Standards and references

• Microsoft 365 Developer Blog: Retirement of Office 365 connectors within Microsoft Teams
• Microsoft Learn: Webhooks and connectors
• Microsoft Learn: Create an incoming webhook
• Microsoft Support: Create incoming webhooks with Workflows for Microsoft Teams
• Microsoft Learn: Manage orphan flows when the owner leaves the organisation
• Microsoft Learn: Manage data policies
• Microsoft Learn: Data policies
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Microsoft Teams Security Guide · Power Automate connections security · Webhook Secrets Security Guide · Microsoft Dynamics 365 and Power Platform Security Guide