4.8 Stars on G2★★★★★GitLab BetaGitLab merge request notifications in Microsoft Teams
One Adaptive Card per merge request, updated live as reviews land, with real @mentions for reviewers. No Power Automate workflow, no connector to migrate.
Works on GitLab Free · gitlab.com groups · No credit card required
.png&w=48&q=75){kind=small}
PullNotifierjust nowTrusted by over 30,000+ engineers across 1,000+ orgs.
.svg)
Why GitLab's built-in Teams integration is not enough
GitLab's "Microsoft Teams notifications" setting is a webhook from 2017. It was never designed for code review, and the connector it depended on no longer exists.
The connector it relied on is gone
Microsoft disabled Office 365 connectors in May 2026, so GitLab’s native Teams integration now needs a Power Automate workflow you build yourself, then edit so it accepts GitLab’s legacy card payload. One Microsoft or GitLab update and it breaks again.
One firehose per channel
Every push, comment, and pipeline event lands as a separate message. A busy project turns the channel into a scrolling log nobody reads, and the merge request that needs a reviewer is buried in minutes.
Reviewers never get pinged
The native integration cannot @mention anyone in Teams. A review request is plain text with a GitLab username in it. Nothing lights up on the reviewer’s side, so merge requests wait.
Game Changer. It covers 99.9% of PR workflows while keeping notifications targeted to only those who need it. The other 0.1% of edge cases is quickly shrinking as they have responded to feature requests super quickly.Merge request notifications built for Microsoft Teams
The notification engine 30,000+ engineers rely on for GitHub and GitLab, delivered as Adaptive Cards in the Teams channel your reviewers already watch.
One Adaptive Card per merge request
Each MR gets a single card in the channel that updates in place. Merged, closed, draft, and reviewer changes all edit the same card, so the channel stays readable.
Approvals and comments stay attached
Approvals, inline diff comments, and discussion replies update the MR’s card instead of spawning new messages. The context stays with the merge request.
Real @mentions for reviewers
Map GitLab users to Teams users once and review requests, approvals, and mentions become real Teams @mentions instead of plain-text usernames.
Channel routing
Set a default channel for the group, override it per project, or route by label, author, or reviewer. Frontend MRs go to the frontend channel, hotfixes to the on-call one.
Noise controls
Draft MRs are skipped until they are marked ready. Mute by target branch, blacklist bot authors, and filter comment notifications by content.
Approval rules that match yours
Tell PullNotifier how many approvals a project needs and the card shows exactly how far each MR is from mergeable.
No Power Automate, no connectors
PullNotifier is a Teams app, not a webhook. Add it from the Apps menu and it keeps working through every Microsoft platform change.
Works on GitLab Free
Per-project webhooks mean no Premium or Ultimate requirement and no group-webhook paywall. Subgroups are fully supported.
Set up in three steps
From zero to merge request cards in Microsoft Teams in about five minutes.
Log in with GitLab
One-click OAuth with your gitlab.com account. No tokens to paste, no YAML to write.
Pick your group and projects
Choose the projects to notify on (Maintainer role required). PullNotifier registers the webhooks for you.
Add the bot in Microsoft Teams
Switch the group to Microsoft Teams, add PullNotifier from the Teams Apps menu, pick a channel, and click Complete Setup on the card it posts.
How the options compare
Four ways to get GitLab notifications into Microsoft Teams, side by side.
| GitLab native integration | Raw webhook or script | Zapier-style automation | PullNotifier | |
|---|---|---|---|---|
| Setup | Power Automate workflow per channel, plus a hand-edited expression | Write and host your own code | One Zap per event type per project | Log in, pick projects, add the Teams app. About 5 minutes |
| After the Office 365 connector retirement | Needs the Workflows migration; known payload bug open | You migrate it yourself | Works, via the vendor’s own Teams app | Unaffected. Never used connectors |
| Messages per merge request | One new message per event | Whatever you build | One new message per event | One card, updated in place |
| Reviewer @mentions in Teams | No | Only if you build user mapping yourself | Limited | Yes, via GitLab to Teams user mapping |
| Route by label, author, or reviewer | No. Event type and branch only | If you code it | With filter steps, per Zap | Built in, per project |
| Skip drafts and bot authors | No | If you code it | With filter steps | Built in |
| Who maintains it | Whoever owns the Power Automate flow | Your team | Your team, per Zap | PullNotifier |
| Cost | Free, plus your time | Hosting, plus your time | Per task. Busy projects get expensive | Free under 4 developers, then per developer |
Native integration details are from GitLab's Microsoft Teams notifications docs and the open payload issue in GitLab's tracker, as of September 2026.
Frequently asked questions
GitLab ships a "Microsoft Teams notifications" project integration, but it is a webhook, not a Teams app. Microsoft disabled Office 365 connectors in May 2026, so it now needs a Power Automate workflow that you build and edit by hand, and it posts a separate message for every event. PullNotifier is a Teams app you install from the Apps menu and connect to your GitLab group in a few clicks.
No. PullNotifier installs as a bot in Microsoft Teams. There is no workflow to build, no webhook URL to paste into GitLab, and no expression to edit when Microsoft changes the payload format.
Yes. PullNotifier never used Office 365 connectors. Notifications are posted by the PullNotifier bot through the Microsoft Bot Framework, so the connector retirement and the Workflows migration do not affect it.
Merge request opened, reopened, merged, closed, draft and ready transitions, title edits, new commits, reviewer and assignee changes, label changes, approvals, inline diff comments, and discussion comments. Each one updates the same Adaptive Card instead of posting a new message.
Yes. Map GitLab users to Teams users once and review requests, approvals, and mentions turn into real @mentions inside the card, so the reviewer gets a Teams notification instead of seeing a plain-text username.
Yes. Set a default channel for the group, then override it per project, or route by label, author, or reviewer from the project settings screen. Each notification goes to the one channel your rules resolve to.
Yes. PullNotifier registers per-project webhooks, which every GitLab tier includes. Group webhooks, a Premium feature, are not required. You need the Maintainer role on the projects you connect.
Not yet. gitlab.com groups are supported today. Self-managed support is on the roadmap, so contact us if your team needs it and we will let you know when it ships.
Each connected group delivers to one platform. Connect the group to the platform your reviewers actually watch. You can switch a group between Slack and Teams from the dashboard at any time.
PullNotifier is free for teams with fewer than 4 developers. Larger teams get a 14-day free trial with no credit card required, then pay per developer. GitLab and GitHub connections are priced the same.
Ship faster with fewer pings
Your next merge request can be one clean card in Microsoft Teams. Set up in minutes.
Continue with GitLab