DIGIT Complaints Management
The complaints resolution and management system
The DIGIT Complaints Management (CMS) is a web and mobile platform for registering and resolving public grievances. Citizens submit complaints anytime, from anywhere. Municipal staff resolve them within defined SLAs. The system is configurable, omni-channel, and built on the open-source DIGIT platform.
CMS was formerly known as Public Grievance Redressal (PGR). You may see references to the older name in some parts of the documentation and user manuals.
Get Started By Role
You are setting up, configuring, or extending the CMS. Start with the architecture, then move through setup → configure → customise.
Your path: Solution Architecture → Quick Install → Configure → Customise
Key references:
You are understanding capabilities, managing rollout, or reviewing performance. Start with functional specs, then workflows and release notes.
Your path: Functional Specifications → Workflows → User Manuals → Release Notes
Key references:
You are planning rollout across departments, ULBs, or states. Focus on governance, tenancy, and SLA design.
Your path: Functional Specifications → User Personas → Master Data Templates → SLA Configuration
Key references:
Browse By Category
📖 Functional Specs
Feature scope, workflows, complaint types, and user personas — the complete functional picture of CMS.
🚀 Setup & Install
Quick install on AWS, production deployment, first-run configuration, and troubleshooting FAQ.
⚙️ Configuration
All 13 configuration areas — workflow, MDMS, SLA, Inbox v2, notifications, boundary, S3, and more.
Setup & Installation
Install the platform
Choose your deployment path first. Use Quick Install for a 1-click AWS deployment with default master data pre-loaded. Use Production Setup for a full Kubernetes deployment.
Complete pre-deployment configuration
Complete all required configurations before deploying the ccrs-services image. Follow this order: Workflow → Master Data → Localisation → Persister → SLA → IDGen → Inbox v2 → Indexer → Boundary → SMS/Email → Google Maps → S3 → Common Guidelines.
Load ULB data after deployment
After deployment, use DIGIT Workbench to load ULB-specific data such as departments, complaint types, and user roles. Quick Install already pre-loads baseline data through the Default Data Handler.
Architecture At A Glance
Solution Architecture
CMS service, Inbox v2, MDMS, IDGen, Persister, Indexer, Kafka, Elasticsearch — and how they connect.
API Specs
Full REST endpoint definitions, request/response schemas, and authentication for the CMS backend.
Data Model
PostgreSQL schema, entity relationships, and field-level definitions for complaints, assignments, and audit.
Configuration Reference
All configurations below must be loaded before deploying the ccrs-services application image. Complete them in the numbered order.
03 · Localisation
Translations for UI labels, error messages, and service names across all languages.
07 · Inbox v2 & Elasticsearch
Advanced inbox filtering and fast search for the v2.11 release baseline.
09 · Boundary
Geospatial boundaries with backend validation and configurable hierarchy support in v2.11.
14· WhatsApp Setup Guide
Instructions for configuring the end-to-end WhatsApp notification ecosystem
What's New — v2.11
CMS v2.11 adds a provider-agnostic notification layer, new configuration services, and stronger local setup tooling.
Highlights:
Provider-agnostic notifications — Route SMS and WhatsApp through configurable providers without code changes.
New platform services — Add Config Service, User Preferences Service, and Novu Bridge.
Bidirectional WhatsApp support — Support consent, template resolution, and richer event payloads.
Improved setup and operations — Add Docker Compose, Kind + Tilt, DataLoader v2, and broader test coverage.
For the full change log, build details, and known issues, use the release references below.
Full Release Notes → Service Build Updates → Test Cases → Migration Guide
Key Concepts
New to DIGIT CMS? These four concepts underpin everything else in the system.
Tenancy
How ULBs and states are isolated. Each tenant has its own data, configuration, and user base within a shared DIGIT instance.
Boundary Hierarchy
State → District → ULB → Ward → Zone. Complaint locations and assignment routing depend on this hierarchy being correctly configured.
Community Resources
Last updated
Was this helpful?