Almanac
Microsoft/teamsMicrosoft 365

Consultant-focused KB for Microsoft Teams: implementation notes, gotchas and configuration decisions beyond the official docs — across chat and collaboration, meetings, webinars and town halls, Teams Phone, PSTN connectivity (Direct Routing, Operator Connect, Calling Plans, Teams Phone Mobile), auto attendants, call queues and contact centre integration, Teams Rooms and devices, apps and extensibility, Copilot in Teams, administration and governance, security and compliance, network and call quality, and licensing — plus cross-cutting decision guides.

feature-apps-workflows-and-connectors-retirement.mdv1 · history
CurrentApplies to AllUpdated 3 weeks agoSource Microsoft Learn ↗

What it does

Workflows is the Power Automate-backed app inside Teams for automating posts, approvals and notifications into chats and channels. It's the replacement for Office 365 Connectors (later renamed Microsoft 365 Connectors), including the old incoming webhook pattern, via the When a Teams webhook request is received trigger.

Key facts

  • Microsoft's final schedule (MC1181996, last updated April 2026) disabled Office 365 Connectors in Teams progressively between 18 and 22 May 2026. As of October 2026, connector-based posting should be treated as gone.
  • The timeline moved several times: new connector creation blocking was announced for August 2024, retirement was extended to December 2025, then to March 2026, April 2026, and finally the May 2026 rollout.
  • Learn still states the connector URLs had to be updated to the new structure to keep posting after 31 December 2024 — a separate, earlier step that caught many tenants.
  • The migration path for webhooks is a workflow using the When a Teams webhook request is received trigger, from a template or built from scratch.
  • Workflows webhooks accept MessageCard-formatted payloads without reformatting (added early 2026), but buttons in MessageCards don't render. Interactive content needs Adaptive Cards.
  • Shared channel posting is supported. Private channel support for Workflows webhooks was rolled out in April 2026.
  • Workflows are owned by a user, not by the team or channel. If the owner leaves, the flow can be orphaned.
  • Admins could disable connectors org-wide with Set-OrganizationConfig -ConnectorsEnabled:$false in Exchange Online PowerShell; changes take up to 24 hours.
  • For ISV and developer scenarios, Microsoft points to a Power Automate connector or a Teams app with proactive bot messaging instead of connectors.

When to use / skip

Use Workflows for the plain cases: monitoring tools posting alerts into a channel, a form submission dropping a card into a team, simple approvals. It's quick, the business can own it, and it's the officially supported route now connectors are retired. If you inherit a tenant where alerts quietly stopped in May 2026, this is almost certainly why.

Skip it when the integration needs to behave like a product — two-way conversation, user-specific responses, proper auth into a back-end system, or high message volume where flow licensing and throttling become a factor. That's a bot or a Power Automate custom connector, built and owned properly.

Configuration decisions

  • Who owns production workflows: a named service account (with appropriate licensing) or individual users. Individual ownership is the main source of orphaned flows.
  • Whether alerting systems post to channels directly via webhook trigger or go through a central flow that formats and routes.
  • Payload format: keep legacy MessageCard JSON for speed, or move senders to Adaptive Cards to get buttons back.
  • DLP: which Power Platform data policies apply to the environment the Workflows run in, and whether the Teams connector and HTTP trigger are allowed.
  • Inventory approach: how to find every system that used to call a connector URL — monitoring, CI/CD, ticketing, home-grown scripts.
  • Whether webhook URLs are treated as secrets and stored in a vault rather than in scripts.

Gotchas

  • The webhook URL is the only credential. Anyone holding it can post to the channel — rotate it if it leaks.
  • MessageCard buttons silently don't render in Workflows. Users report "the approve button disappeared", not "the payload format changed".
  • Flows posting as the owner show that user's identity (or the Flow bot, depending on the action). Agree the expected sender before go-live.
  • Learn's general connectors page still talks about connectors as "nearing deprecation" — the Message Center post carries the actual dates. Don't rely on the docs page alone.
  • Channel deletion or archiving doesn't tidy up the flows pointing at it; they just start failing.
  • Older migration guidance said private channels weren't supported. That's no longer true, but stale internal runbooks may still say so.

Consultant notes

  • On any tenant health check, ask "what used to post into Teams via a connector?" — the May 2026 cut-off left plenty of silent failures.
  • Build a register of webhook-triggered workflows: owner, target channel, sending system, URL storage location.
  • Push for service-account ownership of anything business-critical, and co-owners on the rest.
  • If the client already has a Power Platform CoE or governance process, register Workflows flows under it rather than inventing a parallel one.
  • For contact-centre alerting (queue thresholds, outage notices), a webhook workflow is usually enough; don't over-engineer a bot for it.

Worth revisiting if Microsoft retires the incoming webhook pattern in Workflows itself or changes Power Automate licensing for Teams-triggered flows

Was this accurate?