> For the complete documentation index, see [llms.txt](https://docs.didge.io/home/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.didge.io/home/foodcore-sensors/admin/alerts-and-actions/recipients.md).

# Recipients

**Recipients Configuration for Notifications and Alerts**

The **Recipients** section of the Sensors Dashboard allows system administrators to define which users receive alerts and compliance notifications based on sensor activity. This feature is integral to the notification workflow, ensuring key personnel are informed of temperature breaches and compliance data in real-time.

***

#### Overview

Recipients are categorized by levels, representing a **hierarchy for alert escalation**. Each dashboard can have up to **three recipient levels**, where:

* **Level 1** users receive the first alerts.
* If Level 1 users do not acknowledge the alert, it **escalates to Level 2**.
* If still unacknowledged, it escalates further to **Level 3**.

This hierarchy ensures accountability and provides redundancy in monitoring.

<figure><img src="https://2675140142-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPnSdrHOYeIaTHbt8Z0Qc%2Fuploads%2FOrlc9h6pioXYDwMOrYtj%2FScreenshot%202025-04-19%20at%202.38.34%E2%80%AFpm.png?alt=media&amp;token=c76e6ce9-3c97-44ee-832a-42ad7b391a76" alt=""><figcaption></figcaption></figure>

***

#### Configuring Recipients

To configure recipients:

1. Navigate to the **Recipients tab** on the desired dashboard.
2. Select a user from the **"Search User"** dropdown. The user must already exist in the system.
3. Once selected, their associated contact options will appear:
   * **Email address**
   * **WhatsApp number**
4. Choose how notifications should be delivered:
   * Tick the checkbox next to the email address to enable **email notifications**.
   * Tick the checkbox next to the WhatsApp number to enable **WhatsApp notifications**.

You can add **multiple users** per level and assign them as recipients.

<figure><img src="https://2675140142-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPnSdrHOYeIaTHbt8Z0Qc%2Fuploads%2FhBLg5CdK3HMWlQRIdXQl%2FScreenshot%202025-04-19%20at%202.39.23%E2%80%AFpm.png?alt=media&amp;token=63faab96-012a-499b-829a-b42ae1a117f9" alt=""><figcaption></figcaption></figure>

***

#### Compliance Daily Reports

An additional checkbox, **"Compliance Daily"**, is available next to each recipient. When selected:

* That user will receive the **daily compliance report** summarizing temperature compliance for all sensors on that dashboard.
* This report can be delivered via email.

Each dashboard can have its **own set of compliance report recipients**, providing flexibility per department or location.

***

#### Use Case Scenarios

* **Chef in Kitchen (Level 1)**: Receives first-line alerts during active service periods.
* **Executive Chef (Level 2)**: Escalation point if on-site staff don’t respond.
* **Chief Engineering (Level 3)**: Final escalation for oversight or equipment intervention.

This structure ensures that **alerts are not missed** and provides a clear traceability of who should have acted on an alert.

***

#### Summary

The Recipients system plays a vital role in:

* Delivering **real-time alert notifications**.
* Distributing **daily compliance summaries**.
* Enabling **escalation logic** when alerts go unacknowledged.

Each dashboard should be configured carefully to reflect **operational accountability**, ensuring the right people receive alerts in the correct order of priority.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.didge.io/home/foodcore-sensors/admin/alerts-and-actions/recipients.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.