Routing controls how notifications are delivered once a notification trigger event occurs. It connects notification sources such as alerts or cases to destinations based on labels and routing rules.

## How routing works

Routing uses label-based logic to determine which destinations receive a notification.

```
flowchart TD
    Req["Notification request with labels"]
    Match["Match labels against routers"]
    R1["Router A"]
    R2["Router B"]
    Rules1{"Evaluate rules in parallel"}
    Rules2{"Evaluate rules in parallel"}
    Send1["Send to destinations"]
    Send2["Send to destinations"]
    FB["Fallback connector"]

    Req --> Match
    Match --> R1 --> Rules1
    Match --> R2 --> Rules2
    Rules1 -->|condition true| Send1
    Rules2 -->|condition true| Send2
    Rules1 -->|no match| FB
    Rules2 -->|no match| FB

    class Req entry
    class Rules1,Rules2 decision
    class Send1,Send2 success
```

1. An alert or case generates a notification request.
1. Notification Center matches the request's labels against the routing labels defined in routers.
1. For each matched router, all routing rules are evaluated in parallel.
1. Every rule with a condition that evaluates to `true` sends the notification to its configured destinations.
1. If no rule matches, a fallback connector (if defined) handles delivery.

This separates entity logic (what triggers the notification) from delivery logic (where the notification goes), making routing easier to scale and maintain.

## Routing components

| Component         | Description                                                                                        |
| ----------------- | -------------------------------------------------------------------------------------------------- |
| **Router**        | Logical container for routing rules. A router matches incoming notifications using routing labels. |
| **Routing label** | Key-value pair that filters notifications, such as `environment:prod`.                             |
| **Routing rule**  | Condition that determines which destinations receive the notification.                             |
| **Destination**   | Connector-preset pair that defines where and how a notification is sent.                           |

## Label-based routing

Routers match only when every label defined in the router is also present in the incoming notification. Extra labels in the notification do not affect the match.

The examples below show how router labels are compared with notification labels and whether a match occurs.

| Router labels                                   | Notification labels                              | Result      |
| ----------------------------------------------- | ------------------------------------------------ | ----------- |
| `team:teamA`, `environment:prod`                | `team:teamA`, `environment:prod`                 | Matched     |
| `team:teamA`, `environment:dev`                 | `team:teamA`, `environment:prod`                 | Not matched |
| `environment:prod`                              | `team:teamA`, `environment:prod`, `service:app1` | Matched     |
| `team:teamA`, `environment:prod`                | `team:teamA`, `environment:prod`, `service:app1` | Matched     |
| `team:teamA`, `environment:dev`, `service:app1` | `team:teamA`, `environment:prod`, `service:app1` | Not matched |

Label-based routing lets each team, environment, or service manage notifications independently without duplicating configuration.

## Routing evaluation flow

Flow summary:

1. Notification Center checks all routers.
1. Only routers with matching routing labels are selected.
1. Each matching router evaluates all of its routing rules.
1. Every rule that returns `true` sends a notification to its configured destinations.

Note

- If no router matches, the notification is dropped.
- If a router matches but no rule conditions return `true`, the notification is dropped unless a fallback connector is defined.

```
flowchart TB

    A["Notification triggered"]
    B["Notification request generated"]
    C["Check all routers in Notification Center"]

    D{"Does the router's routing labels match the notification?<br/>(Every router label must be present in the notification)"}

    E1["Add router to matched routers"]
    E2["Ignore router"]

    F["For each matched router, evaluate all<br/>routing rules in parallel"]

    G{"Does a routing rule evaluate to TRUE?"}

    H1["Send notification to the rule's<br/>configured destination<br/>(connector + preset)"]

    H2{"Did the router define a fallback<br/>connector?"}

    I1["Send via fallback connector"]
    I2["Drop notification"]

    %% FLOW
    A --> B
    B --> C
    C --> D

    D -->|Yes| E1
    D -->|No| E2

    E1 --> F

    F --> G

    G -->|Yes| H1
    G -->|No| H2

    H2 -->|Yes| I1
    H2 -->|No| I2

    class A entry
    class D,G,H2 decision
    class H1,I1 success
    class I2 error
```

## Routing conditions

Routing rules use Tera expressions that evaluate to `true` or `false`.

Alert condition examples:

| Condition                               | Description                                     |
| --------------------------------------- | ----------------------------------------------- |
| `true`                                  | Always routes when the router matches.          |
| `alert.highestPriority == "P1"`         | Routes only P1 alerts.                          |
| `alertDef.name is starting_with("CPU")` | Routes alerts where the name starts with "CPU". |

Case condition examples:

| Condition                                | Description                               |
| ---------------------------------------- | ----------------------------------------- |
| `true`                                   | Always routes when the router matches.    |
| `_context.case.priority == "P1"`         | Routes only P1 Cases.                     |
| `_context.case.status == "ACKNOWLEDGED"` | Routes Cases that have been acknowledged. |

See [Dynamic templating reference](https://coralogix.com/docs/user-guides/notification-center/dynamic-templating/index.md) for full syntax.

## Routing behavior

Routing behavior defines how Notification Center processes matches and rule evaluations. Use these scenarios to understand how multiple routers and rules interact.

- Alert notification request 1: `routing.team:teamA` `routing.environment:prod`
  - Router 1: `environment:prod` -- matched because routing label `environment:prod` is present in the notification request.
  - Router 2: `team:teamA` `environment:prod` -- matched because both routing labels `environment:prod` and `team:teamA` are present in the notification request.
- Alert notification request 2: `routing.environment:prod`
  - Router 1: `environment:prod` -- matched because routing label `environment:prod` is present in the notification request.
  - Router 2: `team:teamA` `environment:prod` -- NOT matched because routing label `team:teamA` is not in the notification request.
- Alert notification request 3: `routing.team:teamA` `routing.environment:prod` `routing.service:testApp`
  - Router 1: `team:teamA` `environment:prod` -- matched because both routing labels `environment:prod` and `team:teamA` are present in the notification request.
  - Router 2: `environment:prod` -- matched because routing label `environment:prod` is present in the notification request.
  - Router 3: `team:teamA` `environment:dev` `service:testApp` -- NOT matched because routing label `environment:dev` is not in the notification request.

### Case routing behavior

Cases use the same label-matching logic as alerts. When a Case lifecycle event occurs, Notification Center generates a notification that includes the Case's Ownership Tags -- `environment`, `service`, and `team`. Routers match these tags in the same way they match alert routing labels.

- Case notification request 1: `team:sre` `environment:prod`
  - Router 1: `team:sre` `environment:prod` -- matched because both routing labels are present.
  - Router 2: `environment:prod` -- matched because routing label `environment:prod` is present.
- Case notification request 2: `team:sre` `environment:prod` `service:checkout`
  - Router 1: `team:sre` `environment:prod` -- matched because both routing labels are present.
  - Router 2: `team:sre` `service:checkout` -- NOT matched because routing label `environment:prod` is missing from the router.

Each matching router then evaluates its Cases routing rules separately from alert routing rules. This separation allows teams to manage incident lifecycle notifications independently from monitoring alert notifications.

## Next steps

Configure routing labels on your alerts so routers can match them in [Add routing labels to alerts](https://coralogix.com/docs/user-guides/notification-center/routing/labels-to-alerts/index.md).