Connector configuration

Prerequisites

Some destination types, such as Slack, require you to configure an outbound integration before a notification request can reach the designated connector. Make sure to configure the integration before setting up the connector configuration.

Configuration

Templating for dynamic routing

The Dynamic channel field supports dynamic templating, enabling dynamic routing by inserting variables into the notification configuration. This allows notifications to be sent to different channels within Slack based on alert attributes.

Here are some customization examples:

Example 1: Using alert priority

{{alert.highestPriority}}-interface

• This configuration dynamically inserts the priority of an alert into the channel name.

• The {{alert.highestPriority}} placeholder retrieves the priority level from the alert (alert).

• The notification is sent to a channel with the format: priority-interface (e.g., high-interface, medium-interface).

Example 2: Routing based on the first group’s team ID

{{alert.groups[0].keyValues.teamId}}-interface

• This configuration dynamically routes notifications based on the team ID found in the first alert group.

• The placeholder {{alert.groups[0].keyValues.teamId}} retrieves the teamId value from the first group in the alert.

• The resulting notification channel follows the format: teamId-interface (e.g., engineering-interface, security-interface).

Example 3: Using team name when a naming standard exists

[{{...teamName | lower | replace(from=' ', '')}}-interface]

This ensures the team name is formatted correctly by:

• Converting it to lowercase (lower).

• Replacing spaces with an empty string (replace(from=' ', '')).

The resulting notification channel follows the format: teamname-interface (e.g., devops-interface).

Example 4: Using team name when no naming standard exists

{% set first_group = alert.groups | first %}
{% if first_group is object %}
    {% set team_name = first_group.keyValues | get(key='Team', default='-') %}
{% else %}
    {% set team_name = "-" %}
{% endif %}
{% if team_name == "Supply" %}
    supply-alerts
{% elif team_name == "Billing" %}
    billing-alerts
{% else %}
    techsupport_alerts
{% endif %}

This script determines the notification channel based on the team name in the alert metadata.

If a recognized team name is found, the alert is sent to a predefined channel:

• "Supply" → supply-alerts

• "Billing" → billing-alerts

If no matching team name exists, the alert defaults to techsupport_alerts.

Example 5: Fallback logic based on team name

{% if alert.groups['team_name']%}
  {{alert.groups['team_name']}}-ops
{% else %}
  general-ops
{% endif %}

• If the team_name value exists, the alert is sent to a channel following the format: team_name-ops (e.g., platform-ops, infra-ops).

• If the team_name is not defined or is missing, the notification defaults to the general-ops channel.

• This reduces the need for multiple connectors by using one connector with dynamic routing logic for multiple teams.

Routing Case notifications

Examples 1 through 5 route alert notifications. The Slack connector also routes Case notifications, but Case label variables have a different shape than alert label variables. For the engine-level rules on which variables are arrays and which are direct values, see Label data shapes: alerts vs. Cases.

The shape difference matters for Slack channel routing specifically because a Slack channel name cannot contain square brackets. If a template reads an array-shaped case label without indexing into it (for example {{ case.labels["Service"] }}), the template renders [alerts-mobileye], producing an invalid channel name like [alerts-mobileye]-anomaly-1 instead of alerts-mobileye-anomaly-1. The notification fails to deliver.

Case routing example: by Service label

{% if case.labels["Service"] %}
   {{ case.labels["Service"][0] }}-anomaly
{% elif _context.entityLabels["Service"] %}
   {{ _context.entityLabels["Service"][0] }}-anomaly
{% elif alertDef.entityLabels["Service"] %}
   {{ alertDef.entityLabels["Service"] }}-anomaly
{% else %}
   default-anomaly
{% endif %}

This routes by the Service label, falling back to the next source if a label is missing. case.labels and _context.entityLabels use [0] to index into the array; alertDef.entityLabels is read directly because it is not an array.

Next steps

Define the payload structure for Slack notifications in Message configuration.