> 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/health/release-notes.md). # Release Notes {% hint style="info" %} **Release Date: 22nd Sep 2026** {% endhint %} ## Release Summary HCM v2.1 moves the platform from a campaign execution tool to a full field-operations platform. Three big shifts define this release: * **Configuration moves from build-time to the console** (co-delivery, Polio, hierarchies, stock dispatch, registers) * **Stock ownership moves from the device to the facility**, managed server-side * **Attendance moves from unverified manual records to verified records** (signature or facial recognition), feeding into a structured payment chain The release also adds worker attendance and payments, push notifications, and a re-engineered data ingestion path benchmarked at 20,000 boundaries and 20,000 users. ## Highlights With this release, a health programme can: * **Run much larger campaigns, predictably.** Project creation now scales sub-linearly — doubling the data costs less than double the time. A 50,000-record campaign (20,000 boundaries, 10,000 facilities, 20,000 users) completes in 24 minutes 21 seconds with zero failures. * **Pay and track field workers.** A new worker registry powers attendance registers, muster rolls, and expense claims, integrated with DIGIT-Works and HRMS. * **Reach field users on mobile.** A new Firebase Cloud Messaging push service and a health-domain notification service deliver campaign and task alerts, including scheduled notifications. * **Upload large workbooks in seconds.** The redesigned Excel template is 15.8–18.8× smaller than before, validating 2,300–4,100 rows/second — under 9 seconds even for 20,000 rows. * **Run offline-first deployments.** Parent-existence checks across entities are now off by default, so records can be created while their parent is still queued — with per-service flags to turn strict checking back on where needed. * **Trust delivery guarantees.** The persister now guarantees at-least-once delivery, with failure classification, a dead-letter path, and a terminal parking topic — so one bad record no longer stalls a whole batch. * **Campaign configuration:** * Co-delivery combinations (e.g., AZM+VAS, SMC+VAS) move from hardcoded builds to console setup * Polio is now a supported campaign type, bringing LQAS, Independent Monitoring, and Team Level Stock Details * Multi-hierarchy support lets one tenant run more than one boundary structure at a time **Field operations:** * Stock Management closes gaps seen in ITN, SMC, and co-delivery rollouts, improving accuracy and visibility from warehouses to last-mile distributors * Attendance and Payments adds Console-based register setup, supervisor approval, signature-based marking, and a role-based payment workflow through to bank disbursement * Facial Recognition pilots biometric attendance as an alternative to manual marking * Custom reports let program managers pull campaign-scoped reports from the dashboard, with frequency set during campaign setup. ## New Features #### 1. Polio as a campaign type Polio is now a fully supported campaign type in HCM. The release includes workflows for LQAS, Independent Monitoring, and Team-Level Stock Details, plus visibility into zero-dose children—a key metric tracked in polio campaigns. You can now configure, run, and monitor polio campaigns entirely through HCM. #### 2. Co-delivery, configured through the Console Co-delivery means delivering two interventions together in the same campaign — for example, AZM+VAS and SMC+VAS. This saves time and resources for anyone running a campaign. These combinations can now be configured directly through the Console instead of needing a custom build for each one. #### 3. Multi-hierarchy support Different countries and campaigns organise their administrative areas differently. A single HCM tenant can now support multiple boundary structures at the same time, so different country or campaign structures no longer require a separate tenant each. #### 4. Stock Module revamp Stock balances used to be tied to the device in use, so a logout, device change, or app restart could put the numbers at risk. Stock is now owned by the facility, not the device, so balances hold regardless of what happens to any one phone. This release also cuts down the manual work around stock: * **Bulk stock dispatch** from the Commodity Management dashboard — a single validated Excel upload instead of one transaction at a time * **Real-time stock KPIs and exception flags** — risks surface while there's still time to act, instead of showing up after the fact in a static report * **Live stock visibility on the mobile app** — field teams see what they actually have before heading out, instead of relying on memory or a manual count * **A new web-based Commodity Management module** — one view of transactions and stock across the whole hierarchy for warehouse and national teams, instead of mobile-only visibility #### 5. Attendance & Payments Getting thousands of field workers paid on time depends on how quickly attendance can be set up, captured, and turned into a bill. This release adds: * **Periodic bill generation** — bills can be raised at intervals during a live campaign, so workers aren't waiting until the campaign closes to get paid * **A cross-campaign worker registry** — one record per worker across campaigns, instead of re-entering the same people each time * **Console-driven attendance setup** — create an attendance register and assign users to it, all from the Console * **Offline signature capture** — workers sign on the attendance marker's device, checked against a stored baseline, and it works fully offline * **A full role-based payment workflow** — bills move through Bill Generator, Payment Editor, Payment Reviewer, and Payment Approver, ending in a bank disbursement advisory * **Face recognition** — biometric attendance verification with timestamp, GPS, and confidence score, available as a pilot #### 6. Custom reports Program managers can now access campaign-scoped reports directly from the dashboard and choose the reporting frequency while setting up the campaign on Console. #### What does the release offer different stakeholders? **For field users and programme delivery** * **Worker attendance and payments** — a new worker registry connects attendance registers, muster rolls, and expense claims into one system. * **Push notifications** — app and mobile users now get campaign and task alerts via Firebase Cloud Messaging, including notifications scheduled for later delivery. * **Offline-first data capture** — records can now be created even if their "parent" record hasn't synced yet, so field data collected out of order is no longer rejected. * **Faster Excel templates** — new templates are pre-filled with real data instead of thousands of blank rows, so they're smaller and quicker to work with. * **Multi-hierarchy campaigns** — users can choose which administrative hierarchy to use when creating a campaign. * **Multi-hierarchy complaints** — complaints can now be created and managed across different administrative levels. **For campaign administrators** * **Proven scale** — campaign creation is now benchmarked up to 20,000 boundaries and 20,000 users, with published timings for each phase (see [Performance & Benchmarking](/health/release-notes/performance-and-benchmarking.md)). * **More reliable campaign creation** — user creation in HRMS automatically retries with back-off if it fails, and a background reconciler fixes any user records left inconsistent after a retry. * **Smarter credential sheets** — for users re-added from a past campaign, the sheet now shows their existing username instead of leaving it blank or generating a new one. * **Stricter upload checks** — editing a locked or pre-filled template cell now fails the upload clearly (instead of silently reverting), and key fields like Active/Inactive status and boundary codes are validated on the server. * **Safer boundary re-uploads** — re-uploading a hierarchy that's already present is now simply ignored, instead of returning an error. **For integrators** * **Cleaner campaign resource storage** — campaign resources now live in their own database table with a proper CRUD API, instead of being buried inside a JSON blob. * **New campaign identifier** — a `campaignNumber` field now links attendance registers and stock records, replacing the old campaign ID for those flows. * **End-to-end tracing** — `correlationId` and `tenantId` now travel with every message across Kafka, so a single request can be traced across asynchronous steps. * **Bulk boundary relationships** — a new bulk API (`/boundary-relationships/bulk/_create`) creates up to 100 boundary relationships in a single call. ## New Services
Component (plain name)What it doesHow it's switched on
Worker Registry (worker-registry)Worker registry underpinning attendance and payments; integrates with project-factory user flows and HRMSDeploy the chart plus its DB migration; reads no MDMS
Push Notification Service (egov-notification-push)Firebase Cloud Messaging push delivery to app and mobile usersDeploy with the FCM service-account secret plus device-token migrations
Health Notification Service (health-notification-service)Health-domain and scheduled notificationsDeploy with its persister and indexer configs
Airflow Trigger Service (airflow-trigger-service)Triggers Airflow DAGs for downstream data pipelinesDeploy chart plus config; requires Airflow connection settings
Bulk boundary-relationship path (boundary-management + boundary-service)Batch relationship persistence over a dedicated Kafka topicShips with the services; tunable via BULK_RELATIONSHIP_*
Persister dead-letter pipeline (egov-persister)Isolates poison records; parks terminal failures instead of stalling batchesAlways on; the two new topics must be provisioned on the broker
How to turn on features #### 1. Campaign Resource Table — *always on* Campaign resources now live in a dedicated `eg_cm_resource_details` table rather than inside the `campaigndetails` JSONB column, with a first-class resource CRUD API.
EnableNothing to flip — this is the storage model in v2.1.
MigrationsV20260317100000 adds parentresourceid, filename, isactive; V20260317100001 performs a one-time idempotent backfill from JSONB (guarded by NOT EXISTS).
ConfigPersister topics create-resource-details / update-resource-details → health.eg_cm_resource_details; create-resource-activity → eg_cm_resource_activity.
Existing deploymentsAction required — run the migration during the maintenance window with campaign creation paused, and reconcile backfill row counts before resuming. Backward-compatibility shims retain the old resource APIs.
#### 2. Cross-Entity Validation ("unbundled") — *off by default* Create and update no longer synchronously reject a record whose parent is missing. Structural, uniqueness and required-link checks still run; only parent-existence rejection is relaxed. Flags are read **live at request time** — no restart needed.
EnableSet the relevant flag to true for any environment that requires synchronous parent-existence rejection.
Service settingshousehold.member.relationship.validation=false, project.relationship.validation=false, referralmanagement.relationship.validation=false, individual.beneficiary.id.validation.enabled=false (all defaults shown).
Important caveatWith the defaults, INDIVIDUAL_NOT_FOUND and relative-existence errors on household-member create are suppressed, and a record can be created while its parent is still on the persister queue. This is intentional for offline-first field deployments but changes what the APIs enforce out of the box.
Existing deploymentsAction required if you depend on synchronous rejection — these default to off, so a v2.0 deployment that relied on the old behaviour must set them explicitly.
#### 3. Excel Ingestion Gates Server-side validation of uploaded workbooks, plus a watchdog for the generation listener.
Immutable cellsegov.excel.immutable-reject-on-change=true — editing a server-managed or pre-filled template cell now fails the upload (previously silently reverted). New IMMUTABLE_* error codes.
Value validationegov.excel.usage-value-validation-enabled=true, egov.excel.boundary-selection-validation-enabled=true — stricter Active/Inactive and boundary-code validation.
Sheet protectionegov.excel.join-mode-sheet-protection-enabled=false — User and Facility join-mode sheets ship unprotected.
Listener watchdogexcel.ingestion.listener.watchdog.interval.ms=60000 — scheduled restart of a stopped or zombie generation-init Kafka listener container.
Also includedSerialised async pool plus out-of-memory and generation-time fixes for large (approximately 50,000-row) sheets; new search index V20260530120000 for large sheet data.
#### 4. Bulk Boundary Relationships Relationship creation moved to a dedicated bulk Kafka topic with batch persistence, plus a bulk API.
APIPOST /boundary-relationships/bulk/_create. Hard cap of 100 records per call (boundary.bulk.max.size=100); a larger array is rejected with HTTP 400 BULK_REQUEST_SIZE_EXCEEDED. All callers, including project-factory, must chunk at 100 or fewer.
TunablesBULK_RELATIONSHIP_CHUNK_SIZE=100, BULK_RELATIONSHIP_RETRY_ATTEMPTS=30, BULK_RELATIONSHIP_RETRY_DELAY_MS=2000, RELATIONSHIP_CREATE_CONCURRENCY=10, PERSISTENCE_DRAIN_TIMEOUT_MS=600000.
Central instancesThe bulk relationship topic must not be tenant-prefixed on a central instance.
Behaviour changeAn all-existing re-upload is now an idempotent no-op (previously 400 Boundary already present).
Resourcesboundary-management Node heap raised from 1024 MB to 2048 MB (--max-old-space-size). Single and bulk relationship creates now use separate persister queryMaps — single object versus array.
#### 5. Distributed Tracing Across Kafka — *on by default* `correlationId` and `tenantId` now propagate across Kafka via message headers, with a payload fallback, and the MDC is rebuilt per record on consume.
EnableOn by default. Kill-switch tracer.kafka.mdc.enabled=false.
Versiontracer 2.9.3-SNAPSHOT, inherited transitively via health-services-common.
NoteThis is distinct from the VAPT database-error masking described in section 8 below.
#### 6. Persister Delivery Guarantees — *always on* The persister moved from fire-and-forget to at-least-once delivery with poison-record isolation.
Deliveryenable-auto-commit=false with manual RECORD/BATCH acknowledgement.
Failure classificationBy SQLSTATE — benign (23505), transient (08*, 57*, 40001, 40P01, 53300, 55P03), permanent → dead-letter.
Dead-letter pathBounded reprocessor (max-retries=5), topics egov-persister-deadletter and egov-persister-deadletter-processed.
Database healthPause/resume on database health (persister.db-health.check-interval-ms=5000).
Batch handlingPer-record poison isolation for bulk (bare-array) messages; batch-persist row aggregation; ON CONFLICT (uuid) DO NOTHING idempotency. Batch topics selected via persister.batch.topics or the -batch convention, excluded from the single consumer only when persister.bulk.enabled=true.
OperationsProvision and monitor the two new topics. Parking-topic growth is the terminal-poison signal to alert on.
#### 7. Project Factory Reliability
Boundary syncBOUNDARY_SYNC_RETRY_DELAY_MS=4000 — configurable boundary-sync retry delay.
User creationHRMS per-user create fallback is bounded and retried with back-off and throttling; a poll-time reconciler converges adopted-user rows on retry and surfaces upsert errors. Kafka consumption is at-least-once.
CredentialsThe credential sheet now shows the existing login username for adopted users.
MigrationsV20260612120000 adds retry columns to mapping data; V20260612130000 backfills de-map failed status.
Health probeA Kubernetes health-probe endpoint was added to project-factory.
#### 8. VAPT Security Hardening — *always on*
Database error maskingA DataAccessException handler returns only the root-cause message (code QUERY_EXECUTION_ERROR, HTTP 500) instead of echoing the full SQL or prepared statement. Delivered as a per-service DataAccessExceptionHandler @ControllerAdvice in each service (ticket HCMPRE-1870) — not via a tracer bump.
Services carrying the handlerplan-service, project, census-service, egov-survey-services, service-request, egov-hrms, pgr-services, household, and the DIGIT-Works attendance services.
PII encryptionPersonally identifiable fields are encrypted via enc-client; APIs return encrypted values unless explicitly decrypted.
Hard dependencyThe MDMS DataSecurity.SecurityPolicy master must exist for the target tenant and cover every encrypted model before deployment — otherwise the service fails to boot with a null-pointer exception ("attributes is null"). enc-client loads SecurityPolicy once at startup; adding a missing policy requires a service restart.
### Changed * Added 18 new Flyway migrations and 2 data backfills that run automatically on service boot * Made the project-factory resources backfill idempotent (guarded by a `NOT EXISTS` check) * Disabled row-version validation and raised the search-limit cap for stock user-action updates, to support bulk stock-count updates * Enhanced referral management: added downsync generation auditing, per-category file-size tracking, materialised-view indexes for household addresses, and new `projectId`/`localitycode` columns with indexes * Improved Excel ingestion: added a search index for large sheets and a serialised async pool to cap memory use during 50,000-row generation * Added OpenTelemetry instrumentation to egov-hrms; it now listens for first-attendance-log events to capture worker signatures and photos * Updated the OpenJDK base image across builds * Introduced multi-architecture (amd64/arm64) images for several services and UIs * Added a Kubernetes health-probe endpoint to project-factory * Refactored boundary-service to use separate persister queryMaps for single vs. bulk relationship creation, so bulk publishes now emit one array message per parent code instead of N individual messages ### Fixes
#AreaFix
1Boundary re-uploadRe-uploading an all-existing hierarchy is now an idempotent no-op instead of returning 400 Boundary already present
2Excel templatesEditing a server-managed or pre-filled cell now fails the upload instead of silently reverting the value
3Excel generationOut-of-memory and generation-time failures on large (approximately 50,000-row) sheets resolved
4Excel ingestionA stopped or zombie generation-init Kafka listener container is now detected and restarted by a watchdog
5Campaign user creationHRMS per-user create fallback is bounded and retried with back-off; a poll-time reconciler converges adopted-user rows and surfaces upsert errors
6Campaign credentialsThe credential sheet shows the existing login username for adopted users rather than a blank or regenerated value
7PersisterA single poison record no longer stalls a bulk batch — per-record isolation with dead-letter routing
8PersisterDuplicate-key replays are now benign (ON CONFLICT (uuid) DO NOTHING) rather than failing the batch
9Security (VAPT)API error responses no longer echo SQL or prepared statements (HCMPRE-1870)
10TracingcorrelationId and tenantId are no longer lost across Kafka hops; the MDC is rebuilt per record on consume
11HRMSMobile-number handling fix (HCMPRE-4022)
12PGRUser-type handling fix in health PGR flows
13StockBulk stock-count updates no longer blocked by row-version validation or the search-limit cap
14Boundary throughputRelationship creation no longer serialised per record — moved to a batched bulk topic
## Related Documents | Technical Documents | Functional Documents | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |
  1. Performance & benchmarking
|
  1. HCM Console release notes
| |
  1. Migration guide
|
  1. Stock, attendance, payments & facial recognition release notes
| |
  1. Service build updates
|
  1. Attendance & payments user manual
| |
  1. Worker registry
|
  1. Facial recognition user manual
| |
  1. Stock
|
  1. Stock management user manual
| |
  1. Referral management
|
  1. Configure polio campaign
| |
  1. Health project
|
  1. Configure co-delivery
| |
  1. Project factory
|
  1. Custom reports user manual
| |
  1. Product
| | |
  1. Individual
| | |
  1. Household
| | |
  1. Health notification service
| | |
  1. Facility
| | |
  1. Excel Ingestion
| | |
  1. egov Notification push
| | |
  1. Boundary management
| | |
  1. Beneficiary IDgen
| | |
  1. Complaints service
| | | 19. [Facial recognition](/health/design/architecture/low-level-design/services/platform-services/facial-recognition.md) | | |
  1. Configure custom report dashboard
| | --- # 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/health/release-notes.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.