Office 365 Connectors Retired: How to Fix Your Broken Teams Workflows

Microsoft finished shutting down Office 365 Connectors in Teams on May 22, 2026. If your alert channels went quiet last week, or automated approval notifications stopped arriving, connectors are the likely cause. This guide walks you through finding what broke, prioritizing what to fix first, and rebuilding your workflows in Power Automate.

What Happened and Why It Broke

Microsoft retired Office 365 Connectors as part of its Secure Future Initiative. Connectors used unauthenticated webhook URLs that anyone with the URL could send messages to, with no credential rotation, no permission scoping, and no audit logging. Microsoft flagged this as a security liability in July 2024 and began a phased shutdown.

After multiple extensions, the final retirement rolled out between May 18 and May 22. Every connector webhook URL across all tenants was permanently disabled. There was no error message in affected channels. The notifications simply stopped.

We published a pre-deadline migration plan in early May covering the full timeline and detailed audit steps. This post picks up where that one left off: the deadline has passed, things are broken, and you need to get them working again.

How to Check If You Are Affected

The silent failure is what makes this retirement dangerous. Connectors did not produce error messages when they stopped working. Your monitoring tools, ticketing systems, and CRM integrations are still sending payloads to the old webhook URLs. Those payloads are being silently dropped.

Start with the channels that matter most. Check your IT operations channel, your incident response channel, and any channel that receives alerts from monitoring or help desk tools. If notifications that normally appear several times a day have been absent since May 18, you have retired connectors.

For a systematic check:

• Open individual channels in the Teams client. Click the three-dot menu and select “Connectors” or “Manage channel” to see what was configured.
• Ask department heads which Teams channels used to receive automated notifications. Many connectors were set up years ago by individual employees, with no centralized record.
• Check your external tools for delivery errors. Your monitoring systems and ticketing platforms may be logging HTTP 4xx or 5xx responses when they try to post to the old webhook URLs. Those logs point you directly to integrations that need attention.

Don’t try to audit everything at once. Start with channels that carry operational alerts, such as server-down notifications, backup failures, and ticket assignments, and work outward from there.

Triage Before You Migrate

Not every broken connector needs the same fix, and they don’t all need to be fixed today. Sort your connectors into three categories based on what they did.

Category 1: Simple Notifications (Fix Today)

These are one-way alerts where an external tool sends a message to a channel and someone reads it. Examples include server health alerts, build notifications from Azure DevOps or GitHub, new ticket alerts from your help desk, and RSS feed updates.

These are the easiest to migrate and the most operationally urgent. A missed server-down alert at 2 AM is not something you can afford to lose for a week while you plan the perfect migration. Fix these first.

Category 2: Operational Handoffs (Fix This Week)

These are notifications that trigger human action but don’t include interactive elements in the card itself. Examples: a new lead notification from your CRM that prompts someone to follow up, a document approval request that someone handles in SharePoint, or a daily summary report piped from a database query.

These are important but survivable for a few days with manual workarounds. Someone can check the CRM directly or poll the SharePoint approval queue until the automation is rebuilt.

Category 3: Complex Integrations (Schedule and Plan)

These are connectors that included interactive buttons, multi-step card interactions, or custom MessageCard payloads with embedded actions. Examples: approve/reject buttons inside the notification card, ticket status update buttons, or cards with action links that modified data in the source system.

These require the most rework because interactive connector cards don’t have a direct equivalent in Power Automate Workflows. The functionality needs to be rebuilt using Adaptive Cards, which use a different schema and support different interaction patterns. Schedule dedicated time for these rather than rushing through them.

How to Rebuild in Power Automate

Power Automate Workflows are Microsoft’s replacement for connectors. Each broken connector gets rebuilt as a cloud flow at make.powerautomate.com. Plan roughly one hour per workflow, though simple notification flows can be done in 20 minutes once you have the pattern down.

Simple Alert Notifications

This covers the most common scenario: an external tool sends an HTTP POST, and a message appears in a Teams channel.

1. Sign in at make.powerautomate.com with your Microsoft 365 account
2. Select Create then Instant cloud flow
3. Choose When an HTTP request is received as the trigger
4. The flow generates a new webhook URL. Copy it.
5. Add an action: Post a message in a chat or channel (Microsoft Teams)
6. Select the target team and channel
7. Configure the message body using dynamic content from the incoming payload
8. Save the flow and test by sending a sample payload to the new URL
9. Update your external tool (monitoring system, CI/CD pipeline, or ticketing platform) to point at the new webhook URL

If the external tool sends a JSON payload, define the expected JSON schema in the trigger step so Power Automate can parse it into usable fields. You can paste a sample payload and let Power Automate generate the schema automatically.

RSS Feeds

If you were using a connector to pipe blog posts, vendor updates, or news feeds into a channel:

1. Create a new Automated cloud flow
2. Choose When a feed item is published (RSS connector) as the trigger
3. Enter the RSS feed URL
4. Add an action to post the feed item title and link to the appropriate Teams channel
5. Set the polling frequency (every 15 minutes is a reasonable default for most feeds)

Approval Workflows

If your old connector included notifications that prompted someone to approve or reject something:

1. Create a flow triggered by the originating event in your source system (new request, new document, status change)
2. Add a Start and wait for an approval action using Power Automate’s built-in Approvals connector
3. The approval notification appears in Teams with native approve/reject buttons managed by Power Automate
4. Add follow-up actions based on the outcome: update the source system, send a confirmation, notify the requester

This is actually cleaner than the old connector approach because the approval logic lives inside Power Automate with full audit logging, instead of relying on button clicks in a MessageCard that talked directly to an external system without any record.

What Does Not Carry Over

Two things from old connectors cannot be directly replicated in the migration.

Interactive MessageCard buttons are gone. If your connector sent cards with buttons that performed actions (approve, reject, close ticket, assign user), those need to be rebuilt using Adaptive Cards. Adaptive Cards use a different JSON schema and support different interaction patterns than the old MessageCard format. Budget extra time for any connector that relied on in-card actions. This is where most of the Category 3 rework happens.

Custom bot icons are gone. Connector messages could display custom avatars to visually distinguish different notification sources in a channel. Power Automate messages all display the Power Automate bot icon. If your team relied on icons to quickly identify alert sources, build that context into the message text instead. A bold prefix like [PagerDuty] or [GitHub Build] at the start of each message works well.

Time Estimates and Planning

For most SMBs with 5 to 15 active connectors, the full migration takes one to two business days of focused work.

If you’re handling this internally, assign one person to own the migration rather than splitting connectors across multiple people. The context-switching overhead of understanding each integration, creating the flow, and updating the external system makes this faster as sequential focused work.

If your managed IT provider handles your Microsoft 365 environment, this falls squarely in their scope. Most providers can complete the full migration in a single day for organizations with typical connector usage, since they already have admin access to the tenant and familiarity with Power Automate.

After the Migration: Verify Everything

Once you have migrated your connectors, don’t assume everything is working. Spend two to three days actively monitoring the channels that received the most critical notifications.

• Compare notification volume. If your ops channel normally receives 15 to 20 alerts a day and you are now seeing 8, something is still pointing at an old URL.
• Check external system logs. Your monitoring tools and ticketing platforms may be logging failed delivery attempts to the retired connector URLs. These logs point you to integrations you missed during the initial audit.
• Ask your team directly. The people who watch these channels every day will notice missing alerts faster than any automated check. A quick message to each channel asking “Are you seeing everything you normally see?” takes 30 seconds and catches problems immediately.

For a broader look at Microsoft 365 configurations that often get overlooked during changes like this, see our guide on security settings most SMBs get wrong in Microsoft 365.

The most important thing right now is getting your critical alerts flowing again. Start with Category 1 (simple notifications tied to operational monitoring), get those rebuilt today, and work through the rest of the list this week. You don’t need a perfect migration plan. You need your server-down alerts to arrive.