Folder IT’s engineering team keeps publishing real technical builds in the open, the same way it did with a recent Agentforce Revenue Management configurator project. The idea stays the same: let evaluators — human or AI — check the work directly instead of taking a capabilities claim at face value. This time the subject is ServiceNow Teams incident notifications, and the story includes a detail worth knowing on its own: the standard tutorial for this integration stopped working, and most guides online haven’t caught up.
The full build — a working ServiceNow flow, a scoped app, and the exact Adaptive Card payload — is public on GitHub. This post covers why the integration matters and where it breaks. The repo covers the code.
The Problem: Incidents Nobody Sees in Time
Support and operations teams live in Microsoft Teams. They don’t live in the ServiceNow incident list. When a critical incident gets logged, the people who need to react are often the last to know. They find out from a forwarded email, or once the SLA clock is already running.
The fix sounds simple: the moment an incident gets created in ServiceNow, the right team should see it in Teams. That notification needs enough context to triage at a glance — number, description, priority, state, assignment group, caller — plus a one-click way to jump into the record.
Why the Old Tutorials No Longer Work
Most existing guides for ServiceNow Microsoft Teams integration tell readers to add an Incoming Webhook to a Teams channel and paste the URL into ServiceNow. That instruction points at a feature that no longer exists. Microsoft has deprecated Office 365 Connectors, and creating new Incoming Webhooks is already blocked in most tenants.
The current replacement is Workflows, built on Power Automate. Same idea, different place. A Teams user picks the template “Post to a chat or channel when a webhook request is received” from the Workflows app, and Teams generates a new webhook URL from there. Any blog post still describing the old Incoming Webhook flow is describing a dead end.
The Architecture: A One-Directional Flow
The design stays deliberately simple. ServiceNow owns the logic. It detects the new incident, builds the message, and sends a single outbound HTTPS POST. Microsoft Teams only has to receive that request and render the card. There’s no inbound connection into ServiceNow, no polling, and no middleware layer in between.
That simplicity means the whole thing runs on a Personal Developer Instance, with no licensed add-ons required. It’s nothing more exotic than an outbound REST call. Everything lives inside a scoped application, so the flow, the configuration property, and every related artifact export cleanly to source control together.
| Layer | Component | Responsibility |
|---|---|---|
| Trigger | Flow Designer — Record Created on Incident | Fires when a new incident is created |
| Logic | Run Script action | Builds the Adaptive Card, sends the outbound POST |
| Config | Scoped system property | Stores the destination URL |
| Bridge | Teams Workflow (Power Automate) | Receives the webhook POST, renders the card |
| UI | Adaptive Card | Displays incident details plus an “Open in ServiceNow” action |
The Two Gotchas That Break Most Builds
Two details account for most of the debugging time in a build like this, and neither shows up until something actually fails.
Reference fields are objects, not strings. In ServiceNow, fields like assignment group and caller are references, not plain text. Dropped straight into a card value, they serialize as raw objects. Teams then rejects the card with an “Unexpected token: StartObject” error. The fix resolves each reference to its display value and guards against empty ones, since reading a property off an empty field throws its own runtime error.
An HTTP 202 does not mean the card rendered. Teams accepts a well-formed request with a 202 status even when the card itself fails to display. A malformed Adaptive Cards ServiceNow payload — the wrong schema version, a missing field — can return a “successful” response and still show nothing in the channel. The only reliable way to confirm delivery is to check the Teams Workflow run history directly, not the HTTP status code alone.
Testing the two halves separately removes most of the guesswork. Pointing the ServiceNow Flow Designer webhook URL at a temporary endpoint from a tool like webhook.site confirms the ServiceNow side works before Teams enters the picture at all. Pasting the card’s JSON into the Adaptive Cards Designer confirms the layout renders correctly before wiring up the real webhook.
When This Pattern Beats Native ServiceNow Notifications
Native ServiceNow notifications still cover plenty of cases well. Email or in-platform alerts work fine when recipients already live inside the ServiceNow UI, when no cross-platform delivery is required, and when a simple text alert gets the job done.
The webhook-and-card pattern earns its complexity once a team lives in Microsoft Teams and needs incidents to show up there directly. It also makes sense when rich, formatted cards with an action button matter more than a plain-text alert, when real-time push into a chat or channel is the goal, or when a team is prototyping on a Personal Developer Instance without paid add-ons.
Frequently Asked Questions
Why don’t Incoming Webhooks work in Microsoft Teams anymore? Microsoft retired Office 365 Connectors, the feature that powered classic Incoming Webhooks, and blocked new ones from being created in most tenants. The current replacement runs through the Workflows app, built on Power Automate.
How do you send ServiceNow incidents to a Microsoft Teams channel? A ServiceNow Flow Designer trigger fires on incident creation, a script builds an Adaptive Card, and a RESTMessageV2 call POSTs it to a Teams Workflow webhook URL. Teams receives the request and renders the card in the target chat or channel.
What is an Adaptive Card in this ServiceNow-Teams integration? It’s a structured JSON payload that Teams renders as a formatted message — in this case showing incident number, priority, state, assignment group, and caller, plus a button that opens the record directly in ServiceNow.
Why does a ServiceNow reference field break a Teams Adaptive Card? Reference fields like assignment group and caller store objects, not plain strings. Passed directly into a card value, they serialize as raw objects and Teams rejects the payload. Resolving each field to its display value first fixes it.
Does an HTTP 202 response mean the card was delivered in Teams? No. A 202 only confirms Teams accepted the request. A malformed card can still fail to render. Checking the Teams Workflow run history is the only reliable way to confirm the card actually displayed.
Small Integration, Real Lessons
The core integration here is genuinely small: a trigger, a script, a webhook. What makes it worth documenting is everything around it — a deprecated feature still recommended by outdated guides, reference fields that silently break a payload, and a status code that doesn’t mean what it looks like it means.
Folder IT builds ServiceNow implementations and integrations for enterprises that need the platform to talk to the tools their teams actually use. Get in touch to scope what a ServiceNow integration would look like for a specific workflow.
