Dynatrace Has Both a Slack and a Teams Integration. They Route Independently.

Dynatrace Hub ships both a Slack integration and a Microsoft Teams integration. Both are official, Dynatrace-maintained integrations. You configure them in Settings → Integration → Problem notifications — select Slack, fill in the bot token and channel; select Teams, fill in the Teams webhook URL and channel.

Both integrations work. Each posts Dynatrace problem notifications to its configured platform. A problem opened event fires the Slack notification. A separate Teams notification rule fires the Teams notification.

They are completely independent. The same P1 availability alert does not automatically notify both platforms from a single notification rule. You maintain two separate configurations — two sets of channel mappings, two sets of event filters, two authentication tokens — to cover a mixed Slack/Teams operations team.

The Operational Problem

For a uniform SRE team all on Slack, the Slack integration is sufficient. For a uniform operations team all on Teams, the Teams integration is sufficient.

For the majority of enterprise organizations — where SRE engineers are on Slack, engineering managers are on Teams, DevOps leads are on Webex, and the CTO uses Google Chat — maintaining separate Dynatrace notification rules per platform becomes a configuration maintenance burden.

More critically: when you have separate notification rules, they can drift. Channel names change, bot tokens expire, filter configurations diverge. The on-call Slack channel gets the P1 alert; the engineering leadership Teams channel was misconfigured six months ago and hasn't received an alert since.

Keeping Two Notification Rules Honest

There is no shortcut that collapses the two rules into one. SyncRivo does not accept Dynatrace webhooks, does not route problem payloads, and does not relay messages posted by bots or apps. What works is treating the two Dynatrace notification rules as one configuration:

• Give the Slack rule and the Teams rule the same problem filters (management zones, tags) so both audiences see the same set of problems.
• Review both rules together whenever a channel is renamed or a token rotated.
• Send a test notification from Dynatrace to both rules after any change.

Severity-Based Notification

Use Dynatrace's own notification filters to decide which severities reach which platform:

• AVAILABILITY (highest severity): Slack #on-call and Teams #engineering-leadership
• ERROR (high severity): Slack #sre-team and Teams #engineering-leads
• PERFORMANCE (medium severity): Slack #sre-team only
• RESOURCE_CONTENTION (lower severity): Slack #sre-team only, no Teams escalation

This means separate Dynatrace notification rules with different severity filters. Name them consistently (for example slack-oncall-availability, teams-leadership-availability) so the pairs are obvious.

Problem Resolved Notifications

Dynatrace fires a separate notification when a problem resolves. Make sure both the Slack and Teams rules include resolved events, so the incident loop closes on both platforms without manual follow-up posts.

Where SyncRivo Fits (and Where It Doesn't)

What SyncRivo bridges is the human conversation that follows the alert. Connect Slack #on-call to Teams #engineering-leadership, and the SRE's triage notes, the manager's questions, the decision to fail over, and the customer-update timing are visible on both platforms, in both directions, with threads, edits, files, and @mentions kept in sync. Each channel still receives the Dynatrace problem notification from its own rule; SyncRivo keeps the response from running as two separate conversations.

For the Dynatrace notification setup walkthrough, see the Dynatrace Alerts in Slack & Teams integration guide.