Copy as Markdown[Open in ChatGPT](https://chatgpt.com/?q=Read%20https%3A%2F%2Fcoralogix.com%2Fdocs%2Fuser-guides%2Fnotification-center%2Fdestination-types%2Fslack%2Fconnector-config.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)[Open in Claude](https://claude.ai/new?q=Read%20https%3A%2F%2Fcoralogix.com%2Fdocs%2Fuser-guides%2Fnotification-center%2Fdestination-types%2Fslack%2Fconnector-config.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)

# Connector configuration

## Prerequisites[​](#prerequisites "Direct link to 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](https://coralogix.com/docs/docs/integrations/pull/slack/.md) **before** setting up the connector configuration.

## Configuration[​](#configuration "Direct link to 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.                                                                                |
| **Update the existing Case message** | `updateExistingMessage` | `Boolean` | false    | false                                     | For Case notifications, edit the original message in place as the Case changes, so one message always reflects the current state. Default `false`.                         |
| **Reply in thread**                  | `replyInThread`         | `Boolean` | false    | false                                     | For Case notifications, post each later update as a threaded reply under the original message instead of a new message in the channel. Default `false`.                    |

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**.

## Keep Case updates in one message[​](#keep-case-updates-in-one-message "Direct link to Keep Case updates in one message")

**Update the existing Case message** and **Reply in thread** control how updates to a Case appear in Slack. They apply to Case notifications only: alert notifications always post a new message. The first notification for a Case always posts a new top-level message; the flags govern every update after that.

Note

These options require Slack integration v0.1.0 or later. On earlier integrations they do not appear, and the connector prompts you to add a new integration.

| Update the existing Case message | Reply in thread | What happens on later updates                                                        |
| -------------------------------- | --------------- | ------------------------------------------------------------------------------------ |
| Off                              | Off             | A new top-level message each time (default).                                         |
| Off                              | On              | The update is posted as a reply in the original message's thread.                    |
| On                               | Off             | The original message is edited in place.                                             |
| On                               | On              | The original message is edited in place, and an update is also posted in its thread. |

## Templating for dynamic routing[​](#templating-for-dynamic-routing "Direct link to Templating for dynamic routing")

The **Dynamic channel** field supports [dynamic templating](https://coralogix.com/docs/docs/user-guides/notification-center/dynamic-templating/.md), 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 %}
```

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.

### Routing Case notifications[​](#routing-case-notifications "Direct link to 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](https://coralogix.com/docs/docs/user-guides/notification-center/dynamic-templating/.md#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[​](#next-steps "Direct link to Next steps")

Define the payload structure for Slack notifications in [Message configuration](https://coralogix.com/docs/docs/user-guides/notification-center/destination-types/slack/schema-structure/.md).