## Use Tera templates in routing rule conditions

A routing rule condition is a Tera expression that must evaluate to `true` or `false`.

The system automatically wraps your input with `{{ }}`, so provide only the expression itself.

```text
alertDef.name is starting_with("CPU")
```

This expression evaluates to `true` when the alert name starts with "CPU".

## Alerts

### Condition for alert name starting with certain text

```text
alertDef.name is starting_with("CPU")
```

| Alert name        | Result |
| ----------------- | ------ |
| CPU usage high    | true   |
| CPU saturation    | true   |
| Memory usage high | false  |

### Condition for alert name containing certain text

```text
alertDef.name is containing("CPU")
```

| Alert name         | Result |
| ------------------ | ------ |
| CPU usage high     | true   |
| Database CPU spike | true   |
| Memory usage high  | false  |

### Condition for alert name matching a regex

```text
alertDef.name is matching("(?i)^cpu")
```

- `^cpu` matches alert names starting with "cpu"
- `(?i)` makes the match case-insensitive

| Alert name        | Result |
| ----------------- | ------ |
| CPU usage high    | true   |
| cpu saturation    | true   |
| Memory usage high | false  |

### Condition for alert containing a specific label

```text
alertDef.entityLabels.group is defined
```

| Labels            | Result |
| ----------------- | ------ |
| `group: payments` | true   |
| label not present | false  |

This condition is useful when routing alerts based on ownership labels such as `team`, `group`, or `service`.

### Condition for alert containing a specific value for a label

```text
alertDef.entityLabels.environment == "production"
```

| Environment label | Result |
| ----------------- | ------ |
| production        | true   |
| staging           | false  |

Use this rule to route production alerts separately from staging or development alerts.

## Cases

Routing rules can also evaluate properties from the Cases payload when the entity type is `cases`.

Cases represent incidents created from alerts and move through lifecycle states such as `OPEN`, `ACKNOWLEDGED`, or `CLOSED`. The payload is accessible through the `case` object.

### Condition for case status

Route notifications only when a case is open.

```text
case.status == "OPEN"
```

| Case status | Result |
| ----------- | ------ |
| OPEN        | true   |
| CLOSED      | false  |

Typical use: send notifications only when a case is created or active.

### Condition for acknowledged cases

Send notifications only when a case has been acknowledged.

```text
case.status == "ACKNOWLEDGED"
```

| Case status  | Result |
| ------------ | ------ |
| ACKNOWLEDGED | true   |
| OPEN         | false  |

Typical use: notify stakeholders when an incident has been acknowledged by an engineer.

### Combine case conditions

Route notifications only for acknowledged critical cases.

```text
case.status == "ACKNOWLEDGED"
and case.severity == "critical"
```

| Status       | Severity | Result |
| ------------ | -------- | ------ |
| ACKNOWLEDGED | critical | true   |
| ACKNOWLEDGED | warning  | false  |
| OPEN         | critical | false  |

Typical use: escalate acknowledged critical incidents.

## Entity-type specific routing

Routing rules may process events from different entity types such as alerts or cases. Check the entity type using the `_context.entityType` field.

### Route only case events

```text
_context.entityType == "cases"
```

| Entity type | Result |
| ----------- | ------ |
| cases       | true   |
| alerts      | false  |

This condition ensures the routing rule only applies to case notifications.

### Route alerts but ignore cases

```text
_context.entityType == "alerts"
```

Use this when a routing rule should apply only to alert notifications.

## How conditions differ from other templates

### Boolean only

Regular templates render text, while routing rule conditions must return a boolean value (`true` or `false`).

Invalid:

```text
"CPU alert"
```

Valid:

```text
alertDef.name is containing("CPU")
```

### Do not include {{ }}

The system automatically wraps your expression.

Incorrect:

```text
{{ alertDef.name is containing("CPU") }}
```

Correct:

```text
alertDef.name is containing("CPU")
```

### Missing variables evaluate to false

If a referenced variable does not exist in the payload, the condition evaluates to `false`.

```text
alertDef.entityLabels.team == "payments"
```

If the `team` label is missing, the condition returns `false`. To avoid ambiguity, explicitly check that the field exists:

```text
alertDef.entityLabels.team is defined
and alertDef.entityLabels.team == "payments"
```

## Syntax quick start

### Comparisons

`==`, `!=`, `>`, `>=`, `<`, `<=`

Use `==` and `!=` with any value type. Use `>`, `>=`, `<`, and `<=` only on numeric fields — `case.priority` and `alertDef.priority` are strings (`"P1"` through `"P5"`), so compare them with `==` or `!=`.

String equality, for priorities, statuses, and labels:

```text
case.priority == "P1"
```

Numeric comparison, for fields that hold a number:

```text
alert.value > 80
```

### Logic

`and`, `or`, `not`

```text
alertDef.priority == "P1" or alertDef.priority == "P2"
```

```text
not alertDef.name is containing("test")
```

## Next steps

Create and manage connectors that link Coralogix to third-party services in [Connectors](https://coralogix.com/docs/user-guides/notification-center/connectors/index.md).