> 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/complaints-management-v2.11/digit-complaints-management/page-1.md).
# Page 1
## Release Summary
Complaints Management v2.11 adds a provider-agnostic notification system, Config Service, and **User Preferences Service**. It also brings **full bidirectional WhatsApp integration**, stronger **local development and onboarding tooling**, and broad **security, performance, infrastructure, and UI upgrades**.
## Release Highlights
This release includes:
* A **provider-agnostic notification system**
* **Config Service** and **User Preferences Service**
* **Full bidirectional WhatsApp integration**
* Improved **local development setup** and **onboarding tooling**
* Significant **performance, UI enhancements, and bug fixes**
## New Services
#### 1. Config Service
The new Java-based **config-service** manages notification provider configurations and template bindings. It supports **MDMS v2 schema validation**, CRUD APIs for provider details and template bindings, secure credential handling using **egov-enc-service**, a conditional encryption toggle, state-level tenant support, and Helm-based Kubernetes deployment.
#### 2. User Preferences Service
The new Go-based microservice manages user notification preferences, including **WhatsApp opt-in and opt-out** use cases. It includes CI pipeline support and Helm deployment configuration.
#### 3. Novu Bridge
The new **Novu-bridge** service handles dynamic template resolution across providers such as **Twilio** and **ValueFirst**, without code changes. It also adds **bidirectional WhatsApp integration** with locale-based template resolution, ContentSid and ContentVariables passthrough, and country code formatting. PGR domain events now include metadata such as submitted date, assignee name, designation, and business reference number.
## New Features
#### Notifications and WhatsApp
* Provider-agnostic notification engine — dynamic parameter support with priority-based provider selection (Twilio, ValueFirst, Novu)
* WhatsApp bidirectional design — locale-based template resolution, ContentSid/ContentVariables passthrough to Twilio
* PGR domain events enriched with submittedDate, assigneeName, assigneeDesignation, businessReferenceNumber, and service display name from MDMS for notification templates
* Separate SMS/WhatsApp resolve and search endpoints in the config-service
* Workflow-role-based assignee in complaint domain events (replaces UUID)
* Added ValueFirst provider strategy for SMS and WhatsApp messaging
#### Frontend
* Out-of-the-box OpenStreetMap (OSM) integration, with configuration support to easily switch between Google Maps and OSM.
* Integrated the latest boundary component with a configurable boundary hierarchy. The number of levels to be displayed in the UI, along with the lowest and highest levels, can be easily configured through the HierarchySchema master.
#### Infrastructure and DevOps
* Ansible deployment automation with public registry support (Option C deploy path)
* Kind K8S cluster setup with Tilt live-reload for local development
* Tilt CI workflow for telemetry verification
* Telemetry sidecar container capturing Docker lifecycle events (start, healthy, die, stop)
* Multi-arch Docker build support
* Playwright E2E tests — 33 tests passing (login, complaint creation, workflow, localisation)
#### Data setup
* CRS DataLoader v2 — unified workflow Jupyter notebook with CRSLoader wrapper, load\_hierarchy() for Phase 2a boundary, load\_workflow() for PGR business service
* Redesigned DataLoader v1 Jupyter notebook with improved UX and modular phases
* Boundary hierarchy schema added to MDMS schema definitions with HierarchySchema and test\_load\_hierarchy
* Localisation seed — automated seeding of tenant names and all major localisation modules on compose startup
* Super User role added with bypass of role checks
### Docker Compose Setup
#### Local development
A full **Docker Compose setup** is now available for the Complaints Management stack. It supports one-command startup, localisation seeding, cache busting, Playwright E2E tests, JVM memory optimisation, and telemetry sidecar integration. A **Kind + Tilt**-based Kubernetes dev setup is also available for live reload and CI telemetry validation.
#### DataLoader v2
The new **CRSLoader v2** uses Jupyter notebooks to support the complete onboarding lifecycle, including tenant setup, boundary upload, MDMS configuration, employee creation, localisation, and workflow seeding. It supports modular execution phases, async localisation, dynamic MDMS template generation, Excel validation schema, rollback-enabled E2E tests, CI pipeline integration, and Postman collections.
## Enhancements
#### Platform configuration
* Department name enriched in service requests — displays name instead of code
* STATE\_LEVEL\_TENANT\_ID moved to use a ConfigMap (dynamic from env)
* MDMS v2 endpoint fully migrated from egov-mdms references
* Added PostgreSQL driver class name and corrected database URL key in values.yaml
* Disabled filestore secret by default; enable explicitly when needed
* Cleaned up endpoint whitelists in env.yaml
* Added SMS\_MOBILE\_PREFIX to env.yaml for mobile number formatting
* Mapped boundary role actions for MDMS\_ADMIN and HRMS\_ADMIN
* MDMS\_ADMIN role actions updated for boundary management
* Added missing role actions in actions-test.json and mdms-roleactions
* HRMS\_ADMIN dev mode and default employee password config added
#### Localisation
* Idempotent localisation upserts — deduplication by identity key prevents duplicate batches
* Fixed localisation batch handling and sheet locale/module parsing
* Localization cleanup
* Updated Excel with default localisation messages
* Boundary and complaint type load now auto-generates localisations
* Async processing for localisation data loading
#### DataLoader and Jupyter notebooks
* Localisation batch upserts refactored for reliability
* Auto-detect MDMS service path for different environments
* Fail-fast auth checks (401 handling) across all loaders
* Comprehensive E2E tests with rollback and strict assertions
* Added individual summary report and download links for updated Excel files
* Employee template generation now fetches gender, status, type, and hierarchy types dynamically from MDMS
#### CI/CD
* Added Postman collection tests to CI via Newman
* Telemetry verification across all compose files
* PGR functional readiness check before smoke tests in CI
* Build pipeline for pgr-ui, token-exchange-svc, novu-bridge DB image
* Added `python-dotenv` and `pandas` to the CI pip install
### Frontend
* This release includes multiple UI fixes and enhancements across **PGR Inbox**, **Boundary UI**, **CMS**, and dashboard components.
* Improvements cover search experience, dropdown handling, validation enhancements, localisation fixes, complaint photo upload issues, citizen detail rendering, and core/component library upgrades.
## Bug Fixes
Several critical issues were resolved, including:
* HRMS template syntax problems
* RequestInfo/UserInfo model compatibility issues
* Tenant bootstrap and tenant ID configuration issues
* Fixed REFERENCE\_VALIDATION\_ERR in the default data handler
* Fixed localisation OOM during boundary template generation
* Fixed locality localisation display
* Fixed PGR module bugs for inbox, workflow, and complaint creation
* Fixed console.log placement in Module.js, breaking the build
* Fixed boundary validation checks in UI
* Fixed citizen details 0 render issue
* Fixed employee category localisation key changes
* Fixed preferred language resolution
### Documentation
This release also adds and updates key documentation, including:
* [WhatsApp setup guide](/complaints-management/complaints-management-v2.11/deploy/configure/whatsapp-setup-guide.md)
* [Local development guide](/complaints-management/complaints-management-v2.11/deploy/customise/backend/local-setup/local-setup-cms-service.md)
* [Jupyter DataLoader guide](/complaints-management/complaints-management-v2.11/deploy/setup/production-setup/deploy-complaints-management/configure-cms-data-loader.md)
* [Novu adapter design guide](/complaints-management/complaints-management-v2.11/design/architecture/services/novu-bridge-service.md)
* [Config-service LLD](/complaints-management/complaints-management-v2.11/design/architecture/services/config-service.md)
* Updated Postman collections and service READMEs
* Packaged the CMS product, including all required components, as a 1-click installer on AWS using GitHub Workflows for easier development. Production setup still follows the traditional method.
* The 1-click installer adds all required base master data for the CMS product and core platform to work out of the box. No extra setup is needed to experience the product with the default data.
* Updated changelogs and bumped versions
* Local setup using Tilt and Docker Compose
{% hint style="warning" %}
Hindi localisations are not available on some Citizen and Employee page labels. If you face a localisation issue in the UI and the code contains a dot (`.`), replace it with an underscore (`_`).
{% endhint %}
---
# 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 dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.digit.org/complaints-management/complaints-management-v2.11/digit-complaints-management/page-1.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.