> For the complete documentation index, see [llms.txt](https://docs.digit.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.digit.org/complaints-management/access/configurator-management-guide/notifications.md).

# Notifications

## Overview

This section covers everything to do with keeping citizens and staff informed -  deciding when a message should be sent as a complaint moves through its process, what that message actually says, whether it was successfully delivered, which outside services are connected to send it, and what each person has agreed to receive.

## Manage Notifications

The mechanism runs on Novu (the engine that manages and routes notifications) connected to outside delivery services like Twilio for SMS - plus whichever other providers (email, WhatsApp, etc.) have been added for a particular account.

<table><thead><tr><th width="141.69921875">Item</th><th>What it does</th></tr></thead><tbody><tr><td>Configure</td><td>Decide when a message is sent.<br><br>This is where you set the rules for when a message goes out. A complaint moves through a series of steps as it's handled — filed, assigned to someone, escalated if it's overdue, resolved, and so on. For each of those steps, Configure lets you decide whether a notification should fire, and through which channel (SMS, WhatsApp, or Email). You pick which process you're working with (like the standard complaint-handling workflow), and then go step by step, attaching a message to whichever moments actually deserve one — for example, notifying the citizen the moment their complaint gets assigned to someone.</td></tr><tr><td>Notification Routing</td><td>This governs where a notification is directed once it's triggered — essentially the address book layer sitting behind Configure. While Configure decides "notify at this step," Routing is what would determine which specific recipient, group, or channel destination that notification actually gets sent to, especially in cases where more than one person might need to know (e.g. both the citizen and the assigned officer).</td></tr><tr><td>Notification Templates</td><td>Decide what the message says.<br><br>This is the wording library — the actual sentences and formatting that make up each message. Instead of hand-typing a message every single time something happens, the system pulls from a saved template — e.g. a standard SMS that says something like "Your complaint has been assigned and will be resolved within X days." Templates keep messaging consistent and let you update wording in one place rather than everywhere it's used.</td></tr><tr><td>Provider Templates</td><td>WhatsApp has its own separate template system, governed by WhatsApp's own approval rules — messages sent over WhatsApp Business typically need to be pre-approved by WhatsApp itself before they can be used. This screen is where those WhatsApp-specific, pre-approved message formats are managed and kept in sync, separately from the general Notification Templates used for SMS and Email.</td></tr><tr><td>Notification Logs</td><td>These are the actual outside services that do the real work of delivering a message — the SMS gateway, the WhatsApp Business connection, the email relay. This screen lists every provider currently connected, lets you mark one as the primary choice for a given channel (with backups available if the primary fails), and includes tools to verify a connection is working or send a live test message before relying on it.</td></tr><tr><td>User Preferences</td><td>A record of what each individual — citizen or employee — has personally agreed to receive, broken down by channel: WhatsApp, SMS, and Email. This reflects the person's own consent choices, kept visible so you can quickly check "is this person even reachable by SMS?" before assuming a message should have gone through.</td></tr></tbody></table>

<div align="left"><img src="https://2437503360-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxNs29HvQfLFAPZCcDd7D%2Fuploads%2FDMyqW7qfHeLycsIb2FDI%2Funknown.png?alt=media&amp;token=2186429e-4afa-4ffa-b85b-d935bf06ff3f" alt="" height="336" width="624"></div>


---

# 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.digit.org/complaints-management/access/configurator-management-guide/notifications.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.