GitLab notifications not showing up in Microsoft Teams: 8 causes and fixes

First: find where the chain breaks

A GitLab to Teams notification passes through three hops: GitLab fires the integration, Power Automate receives the webhook and runs a flow, and the flow posts into a channel. Each hop has its own log, so you can locate the failure in two minutes before touching any settings.

1. GitLab side. In the project, open Settings then Integrations then Microsoft Teams notifications and press Test settings. A red banner means GitLab could not reach the URL (cause 1). A green banner only proves the HTTP request was accepted, not that a card was posted.
2. Power Automate side. Open make.powerautomate.com, pick the flow, and read 28-day run history. No runs at all points to causes 1, 4, 5 or 6. Runs that failed on the posting step point to causes 2, 3 or 7. Successful runs with an empty channel point to cause 7.
3. Teams side. Check the channel for a "Workflows" bot post that failed to render, and check whether the channel is standard, private or shared (cause 7).

1. The webhook URL points at a retired Office 365 connector

Symptom: notifications worked for months, then stopped on the same day for every project. Test settings in GitLab fails, or succeeds while nothing ever reaches the channel.

Cause: Microsoft retired Office 365 connectors in Teams. After several extensions (October 2024, end of 2025, March 31 and April 30, 2026), Microsoft disabled connector URLs for good between May 18 and May 22, 2026. GitLab's docs still carry the earlier December 2025 transition deadline. Every GitLab Teams integration created before 2025 used a connector URL, so the old configuration is dead even though the GitLab page still shows it as active.

How to recognize it: a connector URL looks like https://yourtenant.webhook.office.com/webhookb2/.... A Workflows URL looks like https://prod-XX.westus.logic.azure.com:443/workflows/... or https://yourtenant.powerautomate.com/.... If the URL saved in GitLab contains webhook.office.com, this is your problem.

Fix

1. In Teams, open the channel, select the ellipsis next to its name, then Workflows.
2. Pick the template Send webhook alerts to a channel, choose the team and channel, and save.
3. Select Copy webhook link. This is the new URL.
4. Back in GitLab, paste it into the Webhook field of the Microsoft Teams notifications integration and save.
5. Continue to cause 2. The template will not render GitLab's payload until you edit it.

2. The Workflows template expects an Adaptive Card, GitLab sends a connector card

Symptom: the flow runs, the run history shows a failure on the Post card in a chat or channel step, and the error mentions an invalid card, a missing type, or a schema violation.

Cause: the Microsoft template is built for Adaptive Card JSON. GitLab's integration still posts the legacy Office 365 Connector Card format (a MessageCard body inside an attachments array). The template hands the whole payload to the card renderer and the renderer rejects it.

Fix (this is the edit GitLab's own documentation prescribes)

1. Open make.powerautomate.com, find the flow the template created, and select Edit.
2. Delete the action Post card in a chat or channel.
3. Add the action Post message in a chat or channel.
4. Set Post as to Flow bot, Post in to Channel, then pick the team and channel.
5. In the Message field, open the expression editor and paste exactly:

   triggerOutputs()?['body']?['attachments'][0]?['content']

6. Save the flow. Press Test settings in GitLab again and the message should appear.

If you built a custom flow instead of the template, use the trigger When an HTTP request is received with an empty JSON schema, then the same Post message action and expression.

3. GitLab wraps the Adaptive Card in an invalid envelope (issue #565839)

Symptom: you moved to the Adaptive Card path (GitLab merged an Adaptive Card format in merge request !162792 as part of the Workflows migration), and the posting step fails with a validation error. Pasting the payload into the Adaptive Card Designer also reports it as invalid.

Cause: GitLab bug #565839. The payload arrives as { "contentType": "application/vnd.microsoft.card.adaptive", "content": { ... } } while Teams expects the bare card object that starts with "type": "AdaptiveCard". The extra wrapper is the whole problem. The issue was still open when this page was last updated, and it sits alongside #476605, the tracking issue for the whole Teams webhook migration.

Workaround

Unwrap the card inside the flow instead of waiting for the fix. In the Post card in a chat or channel action, replace the card input with the expression:

triggerOutputs()?['body']?['attachments'][0]?['content']

That expression returns the inner content object, which is a valid Adaptive Card. If GitLab ships the fix and starts sending the bare card, the expression will start returning null and you can switch the input back to the raw body. Subscribe to the issue so you know when that lands.

4. Branch or pipeline filters hide the events you expect

Symptom: some events arrive and others never do. Merge requests targeting a feature branch are silent, or you only ever see pipeline failures.

Cause: the GitLab integration has three filters that are easy to forget. The Branches for which notifications are to be sent selector defaults to all branches, but many teams set it to the default branch during setup, which suppresses push and pipeline events for every other branch. Under pipeline triggers, Notify only broken pipelines hides successful runs and Notify only when status changes hides repeated failures.

Fix

• Open Settings then Integrations then Microsoft Teams notifications.
• Set the branch selector to All branches (or Default branch and protected branches if that is really what you want) and confirm it matches the branches your merge requests target.
• Untick the two pipeline checkboxes while you debug, then re-enable them deliberately.
• Save, then open a test merge request against a non-default branch.

5. The right trigger checkboxes are not ticked

Symptom: pushes show up but merge requests never do, or comments on merge requests are missing.

Cause: each event type is a separate checkbox: Push, Issue, Confidential issue, Merge request, Note, Confidential note, Tag push, Pipeline, Wiki page. Merge request comments are Note events, not merge request events, and comments on confidential issues need Confidential note. Someone tidying the integration will often untick Note to reduce noise and remove review comments with it.

Fix

Tick Merge request and Note at minimum for code review traffic, save, and leave a review comment on an open merge request to confirm. Remember the settings are per project, so a group with twenty projects has twenty copies of these checkboxes.

6. The workflow owner left or lost access

Symptom: notifications stopped after someone changed teams or left the company. The flow shows as Turned off or Suspended in Power Automate, or the channel shows a "Workflows" post saying the flow could not post.

Cause: a Power Automate flow belongs to the person who created it and runs under their connections. If their account is disabled, or they lose membership in the team, the flow's Teams connection fails and Microsoft turns the flow off after repeated failures. Nothing on the GitLab side changes, so GitLab keeps reporting success.

Fix

• Have a current team member open the flow in make.powerautomate.com, use Share to add themselves as a co-owner, and re-authenticate the Teams connection under Connections.
• Turn the flow back on. If the original owner's account is already deleted, recreate the flow from cause 1 with a shared or service account as owner and update the URL in every GitLab project.
• Add at least two co-owners so this cannot happen again.

7. The target is a private or shared channel

Symptom: the flow run succeeds, yet nothing appears in the channel, or the Workflows dialog never offers the channel you want in the dropdown.

Cause: the incoming webhook Workflows template supports standard channels. Private and shared channels are either missing from the picker or accept the post without rendering it, depending on tenant settings and the age of the channel. The flow bot also has to be a member of the team that owns the channel.

Fix

Point the flow at a standard channel. If the notifications must stay private, create a standard channel in a private team instead of a private channel in a public team. Then update the channel in the Post message in a chat or channel action; the GitLab URL does not change.

8. How to test the whole chain end to end

1. Prove the URL accepts requests. Paste the Workflows URL into our Microsoft Teams webhook tester and send a sample card. A card in the channel means Teams and the flow are fine and the problem is on the GitLab side.
2. Prove GitLab can reach the URL. Press Test settings in the GitLab integration. Then open Settings, Integrations, and the integration's Recent events tab if your tier shows it, or watch the Power Automate run history for a new run.
3. Prove the payload renders. In the run history, open the failed run, copy the trigger body, and paste the inner content object into the Adaptive Card designer. If it renders there and not in Teams, the wrapper from cause 3 is still being posted.
4. Prove real events fire. Open a merge request against a non-default branch and leave one comment. You should see two posts. If you see one, revisit causes 4 and 5.

Or skip the workflow entirely

Every cause above lives in the Power Automate hop. The GitLab integration was designed for a connector that no longer exists, and the replacement is a flow you own, patch, and re-authenticate by hand in every project. If what you actually want is merge request notifications, there is a shorter path.

PullNotifier for GitLab and Microsoft Teams connects to your gitlab.com group with OAuth and installs a bot in Teams. No webhook URL, no flow, no expression to paste. It posts one Adaptive Card per merge request and updates it as reviews, approvals and merges happen, with the reviewers @mentioned. Setup takes about five minutes with the GitLab + Microsoft Teams setup guide.

What it does not do, so you can decide honestly: it covers merge request events only (no pushes, pipelines, issues or wiki pages), it routes each merge request to one Teams channel (a group default, a per-project channel, or a channel chosen by label, author, or reviewer), and it supports gitlab.com, not self-managed instances. It is free for teams with fewer than 4 developers. Keep the native integration for pipeline alerts if you need them; the two coexist fine.