---
title: What triggers a notification
description: Learn how Notification Center uses entity types and subtypes for alerts and cases.
url: https://coralogix.com/docs/user-guides/notification-center/entity-types/introduction/
product: notifications
feature: Notification Center
feature_id: notification-center
feature_identifier: notifications/notification-center
last_updated: '2026-09-20'
---

# Entity types

Notification Center sends notifications based on entity types. An entity type is a Coralogix component that can generate a notification request, such as an alert or a case. Each entity type contains one or more entity subtypes, which define the structure and schema of its notifications.

Notification Center currently supports two entity types: Alerts and Cases.

## Work with alert entities

Alert entities generate notifications when alert conditions are met. Each alert subtype defines the schema used to format the notification.

### Supported alert subtypes

<!--$?-->

<!--/$-->

All supported alert subtypes, including `EntityType` and `EntitySubType`, are listed in the [Alerts API](https://coralogix.com/docs/api-reference/v5/alert-definitions-service/overview)

### Access alert schema references

* [General reference](https://coralogix.com/docs/user-guides/data-layer/system_dataspace/alerts-history.md)
* Context reference: Describes the `_context` variable for metadata such as trigger details. See [Dynamic templating](https://coralogix.com/docs/user-guides/notification-center/dynamic-templating.md)

## Work with Case entities

Case entities track and manage correlated events in Coralogix. When Case lifecycle events occur, Notification Center generates notification requests that can be routed to external destinations.

### Supported Case subtypes

| Entity | Subtype    | Status         | Description                                                         |
| ------ | ---------- | -------------- | ------------------------------------------------------------------- |
| Cases  | `CREATED`  | `OPEN`         | A Case has been created and is open.                                |
| Cases  | `ACTIVE`   | `OPEN`         | The Case is active and remains open.                                |
| Cases  | `ACTIVE`   | `ACKNOWLEDGED` | The Case has been acknowledged.                                     |
| Cases  | `RESOLVED` | `CLOSED`       | The Case is resolved and closed, with optional resolution metadata. |

All supported Case subtypes are listed in the Cases API reference.

### Notification triggers

Case routing rules support specific lifecycle triggers that control when notifications are sent:

| Trigger             | When it fires                                                                      |
| ------------------- | ---------------------------------------------------------------------------------- |
| Activated           | Impact is confirmed and the Case becomes active                                    |
| Acknowledged        | Someone takes ownership of the Case                                                |
| Unacknowledged      | Someone removes the acknowledgement and the Case returns to active                 |
| Resolved            | Underlying indicators are healthy and the Case is resolved                         |
| Reactivated         | A resolved or closed Case becomes active again                                     |
| Closed              | Follow-ups are complete and the Case is fully finished                             |
| Priority changed    | The Case priority level is updated                                                 |
| Assignee changed    | The Case is assigned or reassigned                                                 |
| KPI breached        | The Case passes its Time to acknowledge, Time to resolve, or Time to update target |
| Olly analysis ready | Automatic analysis of the Case finishes                                            |

Alert routing rules support two triggers: Triggered (when the alert condition is detected) and Resolved (when the condition returns to normal).

### Routing and ownership tags

Cases use Ownership Tags (environment, service, and team) for routing. These are the same attributes used in [Infra Explorer Ownership Tags](https://coralogix.com/docs/user-guides/infrastructure/infrastructure-explorer/ownership.md), so labels already defined on your infrastructure carry through to notification routing.

Unlike alerts, which use explicit `routing.<key>: <value>` labels, Cases inherit their routing labels from the Ownership Tags assigned to the underlying infrastructure.

### Access Case schema references

* General reference: [Case template variable reference](https://coralogix.com/docs/user-guides/notification-center/entity-types/cases.md), covering the `case.*`, `caseMetadata.*`, and `_context.*` namespaces
* Context reference: Describes the `_context` variable for Case notifications. See [Dynamic templating](https://coralogix.com/docs/user-guides/notification-center/dynamic-templating.md)

## Next steps

Explore how entities, routers, connectors, and presets work together in [Core concepts in Notification Center](https://coralogix.com/docs/user-guides/notification-center/core-concepts.md).