How to Route GitLab CI/CD Notifications to Microsoft Teams and Slack Simultaneously

GitLab's Notification Architecture

GitLab supports Slack integration natively via Project → Settings → Integrations → Slack notifications. This integration handles pipeline success/failure, merge request events, issue comments, deployment events, and more. GitLab also supports Microsoft Teams via a similar integration (Project → Settings → Integrations → Microsoft Teams notifications).

The limitation that creates operational friction: each integration is configured separately, and they are configured at the project level. An organization with 15 GitLab projects that needs both Slack and Teams notifications must configure 30 integrations — 15 Slack, 15 Teams. When a new project is created, both integrations must be set up. When a webhook URL changes, it must be updated in 30 places.

GitLab Premium and Ultimate tiers support group-level integrations, which reduces the maintenance surface — but the fundamental single-destination constraint remains.

GitLab Webhooks as the Integration Layer

GitLab's webhook system (Project → Settings → Webhooks) supports the same events as the native integrations but without the single-platform constraint. Configure a GitLab webhook pointing to SyncRivo. SyncRivo receives the GitLab payload and routes to Slack, Teams, Webex, Google Chat, or Zoom simultaneously.

For GitLab Premium/Ultimate organizations, configure the webhook at the group level (Group → Settings → Webhooks) to cover all projects in one step.

Setup (10 minutes per group):

1. In SyncRivo, connect your Slack workspace and Microsoft Teams tenant via OAuth.
2. Create a Webhook source in SyncRivo. Copy the endpoint URL.
3. In GitLab, go to your Group → Settings → Webhooks (or project Settings → Webhooks for free tier). Add a new webhook. Paste the SyncRivo URL. Select Secret Token (optional, SyncRivo supports GitLab's X-Gitlab-Token header). Choose events: Push events, Pipeline events, Merge request events, Deployment events.
4. In SyncRivo, configure routing: pipeline failed → Slack #ci-alerts; pipeline succeeded on main → Slack #deployments + Teams #product simultaneously; merge request merged to main → Slack #engineering; deployment to production → both platforms.

GitLab Event Routing for DevOps Teams

Pipeline failed: This is the highest-urgency CI event. Route to Slack for the engineering team immediately. For failures on protected branches (main, release), also route to Teams for engineering leadership awareness.

Pipeline succeeded on main: Signals a successful build and potential deployment trigger. Route to Slack #deployments for engineers and Teams #product for product managers tracking feature readiness.

Merge request merged: Route to Slack for the development team. For merges into release branches, optionally route to Teams for release managers or product owners who track what is going into the next release.

Deployment event (started/succeeded/failed): One of the most cross-platform-relevant events. Developers care in Slack; product and business stakeholders in Teams care when production deployments happen. Route to both for production deployments, Slack only for staging.

Issue created (by external label or milestone): For GitLab organizations using issues for customer-reported bugs or feature requests, new issues with a specific label can be routed to Teams for the product team that owns the roadmap — while engineering discussions stay in Slack.

Release created: Route to Teams for stakeholders tracking version releases. Route to Slack for engineers who need the artifact reference.

For organizations managing multiple GitLab groups (common in post-M&A environments where acquired entities have separate GitLab namespaces), SyncRivo consolidates notification routing into one endpoint — regardless of how many GitLab groups feed into it.

For the full routing matrix and group-level webhook setup guide, see the GitLab CI/CD Notifications in Slack & Teams integration guide.