> ## Documentation Index
> Fetch the complete documentation index at: https://docs.serial.okos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Alerts

> An in-depth look at the structure and purpose of the `alerts` table in the Serial database

## Introduction to the Alerts Table

The alerts table is designed to store and manage notifications or alerts within the Serial application. This table plays a crucial role in the system by providing a centralized location for storing important messages that need to be communicated to users, often in relation to specific companies or events.

## Table Structure

The alerts table is structured to efficiently store alert information while maintaining relationships with other entities in the database. Here's a detailed breakdown of its columns:

| Column Name   | Data Type                | Constraints                       | Description                                                  |
| ------------- | ------------------------ | --------------------------------- | ------------------------------------------------------------ |
| id            | uuid                     | primary key, not null             | Unique identifier for each alert                             |
| company\_id   | uuid                     | foreign key (companies), not null | Reference to the company associated with the alert           |
| type          | text                     | not null                          | The type of alert (e.g., "OVERRIDE")                         |
| message       | text                     | not null                          | The content of the alert message                             |
| link          | text                     | nullable                          | Optional URL or path associated with the alert               |
| is\_active    | boolean                  | not null, default true            | Indicates whether the alert is currently active              |
| created\_at   | timestamp with time zone | not null, default now()           | Timestamp of when the alert was created                      |
| relevant\_ids | array                    | nullable                          | Array of IDs relevant to the alert (e.g., process entry IDs) |

## Usage and Functionality

The alerts table is designed to be flexible and integrated with the application's notification system. Here are some key points about its usage:

1. **Alert Creation**: Alerts can be created programmatically using the `createAlert` function in `supabaseAlerts.ts`. This function allows specifying the company ID, message, type, link, and relevant IDs.

2. **Alert Retrieval**: The application can fetch alerts using functions like `fetchAlerts` or `fetchAlertsByRelevantIds`. This allows for efficient retrieval of all alerts or filtering based on specific criteria.

3. **Alert Management**: Alerts can be deactivated using functions like `deactivateAlertsByRelevantIds` or `deactivateAlertsById`. This allows for maintaining a history of alerts while controlling which ones are currently active.

4. **Frontend Integration**: The `HomeAlerts` component in the frontend displays active alerts to users. It uses the alert type to determine the appropriate visual style (e.g., warning banner for "OVERRIDE" alerts).

## Notes

* Row-level security is enabled on the alerts table, ensuring that alerts are only accessible to users with appropriate permissions.

* The table supports different types of alerts, which can be extended as needed. For example:

  ```typescript
  export enum AlertType {
    Override = "OVERRIDE",
    // Other alert types can be added here
  }
  ```

* The `relevant_ids` column allows linking alerts to specific entities or events in the system, providing context for the alert.

By leveraging the alerts table, the Serial application can efficiently manage and display important notifications to users, enhancing communication and awareness of critical events or actions within the system.