# Core concepts in Notification Center

Notification Center manages how notifications are generated, formatted, and delivered. It uses a modular model where each function is a distinct component. This page introduces the core building blocks you interact with when creating notification flows.

## Entity

An entity is a Coralogix configuration that generates a notification request, such as an alert definition or a case.

- Each entity has an **entity type**, such as Alerts or Cases.
- Some entity types include **entity subtypes** that support more specific notification behavior.
- Entities provide the data that presets use when rendering a message.

See [Entity types and subtypes](https://coralogix.com/docs/user-guides/notification-center/entity-types/introduction/index.md) for details.

## Router

A router matches incoming notification requests to destinations using label-based rules.

Routers include:

- **Routing labels:** Key-value pairs that identify the request.
- **Routing rules:** Conditions that define which connector and preset to use when a match occurs.

Routers evaluate all routing rules. When a rule’s condition matches, the router sends the notification to all destinations defined in that rule.

Each router contains separate rule views for **Cases** and **Alerts**, allowing teams to manage incident lifecycle notifications independently from monitoring alert notifications.

### How alerts and Cases assign routing labels

- **Alerts** use explicit routing labels with the `routing.<key>: <value>` prefix, added directly to alert definitions.
- **Cases** inherit routing labels from **Ownership Tags** (environment, service, team) assigned to the underlying infrastructure. These are the same attributes used in [Infra Explorer Ownership Tags](https://coralogix.com/docs/user-guides/infrastructure/infrastructure-explorer/ownership/index.md).

Both entity types use the same label-matching logic: a router matches when every label defined in the router is present in the notification request.

See [Routing](https://coralogix.com/docs/user-guides/notification-center/routing/introduction/index.md) for configuration details.

## Destination type

A destination type is a supported third-party service category, such as Slack, PagerDuty, or Generic HTTPS.

Each destination type defines:

- the connector configuration fields required for setup
- the schema that presets use to format messages
- supported payload types

See [Destination types](https://coralogix.com/docs/user-guides/notification-center/destination-types/introduction/index.md) for the full list.

## Connector

A connector is an integration instance that links Coralogix to a destination type. Examples include `slack-workspace-1`, `pagerduty-critical`, or `https-endpoint`.

A connector configuration specifies:

- the connection details and authentication settings for the destination
- optional dynamic fields that use templates for routing or data population
- static or dynamic values depending on the notification source

See [Connectors](https://coralogix.com/docs/user-guides/notification-center/connectors/index.md) for configuration details.

## Preset

A preset is a message configuration that defines the structure and content of a notification.

Presets include:

- templates based on the message schema for each destination type
- a general layer that applies to the entire entity type
- an override layer for specific entity subtypes

Two types of presets exist:

- **System presets:** Provided and maintained by Coralogix.
- **Custom presets:** Created by you and based on system presets, with optional overrides.

See [Presets](https://coralogix.com/docs/user-guides/notification-center/presets/introduction/index.md) for configuration details.

## Destination

A destination combines a connector and a preset. It defines where the notification is sent and which message template is used.

Destinations can be referenced directly in alert definitions or through routers.

## Component relationships

The components work together as follows:

1. An entity generates a notification request.
1. A router matches the request using routing labels.
1. The router evaluates its routing rules. Each rule defines a condition and one or more destinations.
1. If a rule matches, the connector sends the formatted message (based on the preset) to the destination type.

## Next steps

Learn how label-based routing delivers notifications to the right destinations in [Routing](https://coralogix.com/docs/user-guides/notification-center/routing/introduction/index.md).