Connector Configuration

This guide presents the connector configuration for the Slack destination type.

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

UI label	API Field name	Type	Required	Allows notification source type overrides	Description
Name	`integrationId`	`String`	true	false	Slack integration identifier.
Description	`description`	`String`	false	false	Description of the integration.
Integration	`integration`	`String`	true	false	The Slack workspace to which notifications are sent.
Channel	`channel`	`String`	false	true	The Slack channel to which notifications are sent. Acts as the test channel.
Dynamic channel	`dynamicChannel`	`String`	true	false	Includes one or more data-driven variables that direct the notification to different channels based on the fulfillment of conditions. Overrides the Channel selection.
Fallback channel	`fallbackChannel`	`String`	true	false	If a notification to the defined channel fails, it will be routed to this fallback channel.

Note

If a rendering error occurs during the notification message creation, a message is sent to the predefined Channel. If it cannot be delivered there, it is delivered to Fallback channel.

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

{{alertDef.priority}}-interface

This configuration dynamically inserts the priority of an alert into the channel name.
The {{alertDef.priority}} placeholder retrieves the priority level from the alert definition (alertDef).
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 %}

This configuration routes notifications based on the team_name field found in the first alert group.

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.

Message Configuration

Next Message Configuration