# 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](https://coralogix.com/docs/integrations/pull/slack/index.md) **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](https://coralogix.com/docs/user-guides/notification-center/dynamic-templating/index.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**

```js
{{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**

```js
{{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**

```js
[{{...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**

```js
{% 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**

```js
{% 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

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/user-guides/notification-center/dynamic-templating/#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**

```js
{% 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](https://coralogix.com/docs/user-guides/notification-center/destination-types/slack/schema-structure/index.md).