Water & Sewerage - Privacy Exemplar

Survey Test Cases

New UI to Old UI

Birth & Death Reports

Help FAQ Section in Citizen UI - Common Framework (Product-Specific Pages)

PGR Notifications

W&S UX/UI Revamp

Bill Amendment For W&S

W&S Reports

Bill Genie

TL Reports

Finance DSS

BPA

DSS Test Case For 3 KPIs

OBPS Reports

Release Summary

DIGIT 2.8 release includes 1 new module, several new products, functional and security features, regression testing, bug fixes of previously released modules and a few non-functional changes.

New Module

Citizen engagement - Survey service

Functional Changes

• OBPS Tabular Reports in old UI/UX, Trade Licence Tabular Reports in old UI/UX

• Notification based on channels - PGR, OBPS & mCollect

• Help/FAQ section in Citizen UI - common framework - integration with all the modules

• Bill Genie UI/UX revamp

• Survey module

• Water & Sewerage UI/UX Revamp, Bill amendment workflow update & UI/UX revamp, W&S disconnection

• Water & Sewerage Privacy Exemplar, Standard Reports for W&S - Receipt Register, Collection Register, Defaulters Report - in old UI/UX

• Birth & Death Tabular Reports - in old UI/UX

• Enhancement on DSS, Finance Module State DSS, NSS Adaptor, Enhancements in National Dashboard- FAQ & About page.

Non-functional Changes

• Navigation re-direction from New UI to OLD UI

• Bulk Bill PDF generation and performance testing

• W&S Bulk Bill generation and performance testing

New ‌Feature Additions

Enhancements

Success Metrics

https://docs.google.com/document/d/1b4plZ0TFMJC53MDt72_sx-Wif2bdR4I5dnD9DTN40Ss/edit

Adoption Metrics

Adoption of new features will be tracked on the basis of the following metrics:

‌Document Resources and Links

UI Technical Documents

1. Employee: Water and Sewerage Application Details

2. Employee: Water and Sewerage Connection Details

3. Employee: Water & Sewerage Modify Create Flow

4. Employee: Water and Sewerage Modify Application Details

5. Employee: Disconnection Water & Sewerage Create Flow

6. Employee: Water and Sewerage Disconnection Application Details

7. Employee: Ad-hoc Rebate/Penalty and View Breakup in application details.

8. Citizen: Water & Sewerage Create

9. Citizen: Water & Sewerage - My Applications

10. Citizen: Water & Sewerage - My Connections

11. Citizen: Water and Sewerage Disconnection Application Create

12. Citizen: Water and Sewerage Disconnection Application Details

13. Privacy - UI

14. Employee: Bill Amendment - Create Flow

15. Employee: Bill Amendment - Search, Edit & Resubmit, Approve, Reject & Send-Back Flows

16. UI- Tech Documentation on Bill Genie and Group bill screens

17. Bill Genie:: Employee: Search Bills

18. Bill Genie:: Employee: Group Bills

19. Bill Genie:: Employee: Download Bill

20. Help/FAQ section Citizen UI

21. National Dashboard - About & FAQs

22. Navigation between Old and New UI

Updated docs

1. Trade License - Apply Flow

2. New Trade License Application

Backend Service Documents

1. Birth and Death Service

2. State DSS - Birth and Death Technical Documentation

3. Water & Sewerage-State DSS- Technical Documentation

4. National Dashboard-W&S Technical Documentation

5. Water and Sewerage Service Technical Documents

6. Guidelines for supporting User Privacy in a module

7. Encryption Client Library

8. Water Service - Disconnection

9. Sewerage Service - Disconnection

10. Sewerage Disconnection Calculator Service

11. Water Disconnection Calculator Service

12. W&S: Privacy Changes Backend Technical Documentation

13. National Dashboard Adaptor Service

14. Workflow config-Replacement data-Migration Document for Bill Amendment W&S

15. Survey Service

Bill Amendment (Billing-service)

W&S Bill Amendment workflow config migration

• Follow the steps mentioned in the W&S Bill Amendment Workflow config migration document.

• Verify once if workflow name is hardcoded except edited parts of UI, Backend - check in indices and report - checked not present except config

• Verify if wf config is there for tenant level or state level only

• An update has to be added as a patch to the first release of the amendment

Water & Sewerage

• Latest persister file - Water

• Latest persister file - Sewerage

• Water modify connection

  • Workflow config

• Sewerage modify connection

  • Workflow config

• Sewerage Disconnection

  • Workflow config

• Water Disconnection

  • Workflow config

Privacy Feature

By default encryption & privacy is disabled for 2.8

• To disable privacy for Property and W&S make changes in the MDMS- DataSecurity -> SecurityPolicy.json file.

• For models- Property,PropertyDecrypDisabled, WnSConnection, WnSConnectionOwner, WnSConnectionDecrypDisabled, WnSConnectionOwnerDecrypDisabled, WnSConnectionPlumber, WnSConnectionPlumberDecrypDisabled; insert only one attribute in the attributeList as follows:

 {
         "name": "sample",
         "jsonPath": "sample",
         "patternId": null,
         "defaultVisibility": "PLAIN"
    }

• Insert the name and jsonPath which are not actually expected to be present in the RequestBody/ResponseBody

• Files to be updated

  1. Security policy complete file

  2. Masking patterns - needed only if enc is enabled and carried our for old data.

• References for reading

  1. PT,W&S decryption policy

  2. Decryption Disabled config for PT,W&S

  3. W&S Plumber enc/dec

  4. Inbox decryption config

  5. Reindexing enc/dec config

• Once the above changes are done deploy the following builds:

  1. Ws-services

  2. Property-services

  3. Sw-services

  4. Inbox

  5. Restart egov-user service

• Impact of privacy framework

  1. The privacy implementation masks the PII information based on the MDMS config (Security Policy)

  2. The masking/unmasking of data is entirely dependent on the roles of the users in the system, adding or removing these roles from the config will enable masking for each role.

  3. There is no module-level control here, so if a W&S role is added to an employee of TL then data will be masked so cross-using of roles should be avoided.

  4. The agreement with Manish is that the privacy be disabled until redesign with the module filter - Done

  5. The policy should be defined for adding or removing fields from the encryption process.
• W&S privacy (Skip over if encryption is not carried out)

  1. Deploy the latest builds provided for the 2.8 release {builds}

  2. Add privacy configs to MDMS (SecurityPolicy.json)

  3. Restart the MDMS service followed by the encryption service

  4. Add the temporary index config update index with encrypted data

     • This file will fetch data from the Encryption of old data and upload it to the existing index so that the index will be encrypted or masked as per config.

  5. Trigger the encryption of old data through the provided APIs

  6. Validating the encryption of old data {Doc Link}

  7. Disable & enable decryption.privacy

     • water.decryption.abac.enabled=true

     • sewerage.decryption.abac.enabled=true

• PT privacy (Skip over if encryption is not carried out)

  1. Deploy the latest builds provided for the 2.8 release

  2. Add privacy configs to MDMS (SecurityPolicy.json)

  3. Restart the MDMS service followed by the encryption service

  4. Add the temporary index config update index with encrypted data

  5. Add the new index config for the fuzzy search index

  6. Trigger the encryption of old data through the provided APIs

  7. Validating the encryption of old data {Doc Link}

  8. Disable & enable decryptionprivacy

     • property-decryption-abac-enabled: "true"

• Bill genie

  1. No changes required

• Bulk Bill PDF Generation and Performance Testing

  1. Enhancement is part of the new build release.

• W&S Bulk Bill Generation and Performance Testing

  1. PR List

     • W&S calculators

     • Bug Fixes on calculators

     • Billing service
• privacy integration - PT

  1. Covered as part of privacy above

• Notification based on channels - PGR

  1. Localisation added as part of the release KIT

• Notification based on channels - mCollect

  1. Localisation added as part of the release KIT

• OBPS/ BPA (Notifications only)

  1. Localisation added as part of the release KIT

• National Dashboard Adaptor Integration Testing

  1. The Docs are specific to Punjab implementation, generic product document is in the pipeline.

• NationalDashBoard 3 New KPI

  1. CharApiConfig.json

  2. MasterDashboardConfig.json

     • Overview Card config

     • Property Tax config

  3. DevOps change

• Finance Module State DSS

  1. Dss Chart API config

• MDMS & Configs -

  1. Complete Localisation

  2. Complete MDMS

  3. Complete configs

BackWard Compatibility Results -

• Folder Link

UI Changes

Please add all MDMS changes before deploying the UI code.

• W&S: W&S UI/UX Revamp

  • No changes are needed, it will work automatically if we deploy. There are two enhancements in the W&S flow, i.e Edit by normal user and Edit by config user, it is based on the MDMS configuration (Link). This is applicable in all 3 flows.

• W&S disconnection

  • No changes needed, it will work automatically if we deploy.

• Bill amendment W&S UI/UX RevampI

  • No changes needed, it will work automatically if we deploy.

• Bill Genie UI/UX revamp

  • No changes needed, it will work automatically if we deploy.

• OBPS Tabular Reports in old

  • No changes needed, it will work automatically if we deploy. It is based on the configuration of the backend.

• TL Tabular Reports

  • No changes are needed, it will work automatically if we deploy. It is based on the configuration of the backend.

• Standard Reports for WnS

  • No changes are needed, it will work automatically if we deploy. It is based on the configuration of the backend.

• Core UI Changes (Banner Images of Each module)

  • No changes are needed, it will work automatically if we deploy. It is based on the configuration of the MDMS (Link)

  • We need to add the below images in the S3 bucket:PGR: https://egov-uat-assets.s3.amazonaws.com/PGR.png

  • PT: https://egov-uat-assets.s3.amazonaws.com/PT.png

  • TL: https://egov-uat-assets.s3.amazonaws.com/TL.png

  • OBPS: https://egov-uat-assets.s3.amazonaws.com/OBPS.png

  • FSM: https://egov-uat-assets.s3.amazonaws.com/FSM.png

  • WS: https://egov-uat-assets.s3.amazonaws.com/WS.png

  • Bills: https://egov-uat-assets.s3.amazonaws.com/Bill.png

• Navigation re-direction from New UI to OLD UII. Mdms Changes are required for this (Link).

Old UI

Only Fire Noc and Tabular reports are PO signed off in the current release for the OLD UI, the rest of the modules are covered as part of backward compatibility tests shared above.

Overview

This release provides UI/UX revamp of existing features of water and sewerage modules in addition to applying for disconnection, data privacy, and 3 standard reports.

Release Highlights

UI/UX revamp of water and sewerage covers the features given below.

Citizen

1. My Connections

2. My Applications

3. My Payments

4. My Bills

5. Search and Pay

6. Apply for a new connection

7. Apply for disconnection

8. View Connection Details

9. View Consumption Details

10. View Application Details

11. Pay Water and Sewerage Bill

12. Pay Application Fee

Employee

1. Water Inbox

2. Sewerage Inbox

3. Apply for a new connection

4. Modification of connection

5. Bill Amendment

6. Application Workflows

7. Search Connection

8. Search Application

9. View Connection Details

10. View Consumption Details

11. Add Meter Reading

12. View Application Details

13. Collect Application Fee

14. Collect Water and Sewerage Bill

Downloads/ PDFs

1. Connection Details

2. Application Acknowledgement/ From

3. Estimation Notice

4. Sanction Letter

New Features Added

1. Disconnection of water and sewerage connection.

2. Disconnection Notice PDF

3. Application acknowledgement/form PDF

Reports

1. Receipt Register

2. Collection Register

3. Defaulters Report

Data Privacy

1. Masking of PII data

2. Option to unmask the PII data

3. Audit trail of the unmasking of PII data

Release Features

Known Issues

Upcoming Release Features

None

Reference Doc Links

Overview

This release provides the UI/UX revamp of OBPS , workflow timeline changes and reports.

Release Highlights

The functionality in OBPS remains the same - only the UI/UX has changed.

Two reports added for administrative purposes.

Changes made to the workflow timeline for clear representation of application status to the users.

Notiification based on channels.

Release Features

• Stakeholder registration and employee approval flow

• Architect flow (permit application creation) and employee approval flow

• Architect occupancy certificate creation and employee approval flow

• Fire NOC employee approval flow

• Open link for stakeholder registration flow

• Daily collection report

OBPS application status report

Workflow timeline changes in application flow - The image below the one illustration on the right displays the old status view. Here the application status shows pending even if the task is completed. As per the current release, the application displays only the current state where action is marked as pending. The remaining status is marked as done or completed or in submitted state.

Notification based on channels - The OBPS application allows the user to configure different messages for different channels (In app, mobile messages, email) for the same event in the application process flow.

Known Issues

Upcoming Release Features

None

Reference Doc Links

Overview

Few reports are added to the TL module for administrative purposes.

Release Highlights

TL Daily collection report

TL Application status report

Trade license registry

Trade license renewal pending report

Release Features

TL Daily collection report

TL Application status report

Trade license registry

Trade license renewal pending report

Known Issues

https://digit-discuss.atlassian.net/browse/UM-5286 https://digit-discuss.atlassian.net/browse/UM-5625 https://digit-discuss.atlassian.net/browse/UM-5682 https://digit-discuss.atlassian.net/browse/UM-5547 https://digit-discuss.atlassian.net/browse/UM-5554 https://digit-discuss.atlassian.net/browse/UM-5692

Upcoming Release Features

None

DIGIT 2.8 release has a new module, new features, bug fixes and a few non-functional changes.

Account Wise Feature Demand

Punjab W&S is using the old UI. So W&S new features, which are using new UI, cannot be used in Punjab

NUDM Roll Out

The following features are part of the UPYOG Product Roadmap and will be released as part of UPYOG 2.0 by end of March 2023.

*As per current demand from NUDM-enabled states

Adoption Metrics

Adoption of new features will be tracked on the basis of the following metrics:

Overview

UI/ UX revamp of Bill Amendment.

Release Highlights

UI/UX revamp of Bill Amendment Inbox and Application View.

Release Features

Known Issues

None

Upcoming Release Features

None

Reference Doc Links

Overview

This release provides PRDs of 3 property tax features and a few bug fixes.

Release Highlights

PRDs of 3 property tax features and bug fixes.

1. Properties amalgamation

2. Property bifurcation

3. Capital value system

4. Property mutation bug fixes.

Release Features

None

Known Issues

Bug

Upcoming Release Features

None

Reference Doc Links

Overview

This module gives citizens more information on a service delivery module than just links to access the service.

Release Highlights

Product Specific Pages Module consists of the following:

For Citizen

For a module and tenant that is configured.

1. FAQs

   • List of FAQs for each module

2. How it works

   • List of user manuals, help videos etc (Also in local language)

3. Link to access service via WhatsApp

4. Helpline Numbers

5. Address of Service Centres

   • Link to navigate to google maps

6. Static data

   • Ex. Days to process applications/ Amount to pay while applying etc

7. Dynamic Data

   • Number of citizens applied for service in last n months/ Amount collected etc

Known Issues/ Upcoming Features

https://digit-discuss.atlassian.net/browse/UM-5628 https://digit-discuss.atlassian.net/browse/UM-5721 https://digit-discuss.atlassian.net/browse/UM-5640 https://digit-discuss.atlassian.net/browse/UM-5725

Mockups

Related Doc Links

Overview

This module allows employees to create surveys for citizens and let them fill out surveys. Later survey results can also be seen on the Survey results dashboard.

Release Highlights

The Survey module consists of the following

For Employees

1. Surveys section on Home Page

2. Surveys inbox

3. Create survey

   • Meta Data - Title, Description, Survey start & end date/time

   • Questions

     • Short Answer

     • Paragraph

     • Single Answer

     • Multiple choice questions

     • Date

     • Time

4. Survey Results

   • Aggregated view of all survey results in specific charts for each question type

   • Download the excel report with the survey results

5. Modify surveys

   • Survey questions

   • Extend the Survey date and time.

For Citizens

1. Notification on Survey creation.

2. Survey Filling

Known Issues/ Upcoming Enhancements

1. Expansion to other types of questions

2. More notifications to citizens prior to survey start, and survey end.

3. Making surveys open. (Right now citizens need to be logged in to fill out the survey. This needs to be made open)

https://digit-discuss.atlassian.net/browse/UM-5697 https://digit-discuss.atlassian.net/browse/UM-5700

Mockups

Related Doc Links

MDMS Changes

Config Changes

Service Build Updates

Overview

UI/ UX revamp of Bill Genie.

Release Highlights

UI/UX revamp of Bill Genie features.

Release Features

Known Issues

None

Upcoming Release Features

None

Reference Doc Links

Overview

Reports have been added to birth and death for administrative purposes.

Release Highlights

Birth count report

Death count report

Birth and death certificate payment records

Release Features

Birth count report

Death count report

Birth and death certificate payment report

Known Issues

https://digit-discuss.atlassian.net/browse/UM-5256

Upcoming Release Features

None

DIGIT is an open-source platform licensed under the MIT license (https://opensource.org/licenses/MIT) compliant with the NUIS digital blueprint.

Detailed mapping of DIGIT’s capabilities with the core requirements mentioned in the NUIS digital blueprint has been done below:

Interoperability

Data specifications/models are available for domain entities. DIGIT is designed as an API-first platform wherein data specs/models are created for all key entities thus ensuring interoperability through open APIs and open standards. Taxonomies are available for the key domain entities/registries. These can later be harmonised with standard taxonomies in the domain as and when they are made available.

DIGIT data models and APIs are published as Open APIs freely available to everyone in the ecosystem. In Punjab, the DIGIT module was easily integrated with 3rd party payment apps like Paytm, Airtel Money, BBPS, etc to increase citizen access and improve collections. At present, DIGIT provides at least 3 key distinct APIs for all domain entities - create, update and search.

Deactivation/Cancellation of key entities in DIGIT is achieved by updating their status to inactive as per their defined specification/API contracts. Given the API-first and micro-services-driven nature of DIGIT, current APIs and models can be quickly harmonised with national standards as and when they are made available. DIGIT strives to leverage established domain standards (national/international) wherever available.

Data Privacy And Security By Design

Data Privacy

Data privacy capabilities are available to mark and protect sensitive data. The core service layer of DIGIT includes signing and encryption service as one of the core services that provide capabilities to sign/encrypt/mask sensitive data. It is designed such that it can work against software key stores and can be extended to integrate with any kind of hardware key store to store and protect signing and encryption keys.

Encryption requirements can be defined and adhered to for the storage of sensitive data. DIGIT requires the User PII data to be stored in its User service which is by default enabled for encryption of sensitive data as User Data Vault. All other services in DIGIT are required to access PII data by explicitly calling the User service - which in turn audits all access to PII. In addition, individual services in DIGIT can leverage DIGIT’s signing and encryption service (which is what User Service leverages to create User Data Vault) to further protect additional sensitive data available with the services.

DIGIT provides the capability to define workflows for data modification that can be configured to have approval steps to get needed consent for any data modification activities. DIGIT currently provides RBAC (Role-Based Access Control) based access control for access (search) to data.

Security

Appropriate access controls can be defined in the APIs to ensure authorised access to sensitive data. DIGIT is designed to handle authentication and authorisation as perimeter control at its API gateway layer to ensure unauthorised calls are not allowed to even contact the respective micro-services. DIGIT provides an RBAC (Role-Based Access Control) mechanism where users are explicitly provided access to relevant resources by assigning them appropriate roles. By default, DIGIT supports OAUTH-based authentication for individual users and APIs. However, the Authentication and Authorization filter on DIGIT is designed to be easily extendable to support any further Auth and Auth needs.

The perimeter security mechanism in DIGIT also helps developers in focusing on the functional developments in further services and offload the access control requirements for new resources and their APIs to the API gateway using simple configurations.

DIGIT also ensures that risks like the following are taken care of:

• Privilege escalation – form field manipulation

• Failure to restrict URL access

• Insecure direct object references (IDOR)

• Malicious file upload leads to cross-site scripting

• Improper authentication

• Missing account lockout

• Request throttling attack

• Weak encoding mechanism

• Sensitive information in URL

• Lack of automatic session expiration

• Insecure banner implementation

• Concurrent session

• Clickjacking

• Improper error handling

Transparency And Accountability Through Data

DIGIT has the capability to define key registries in OpenAPI 3.0 specs formats and easily achieve key APIs like create/update/search using its building blocks in core services mainly through configurations and using lightweight extensions on a needs basis.

DIGIT has the capability to protect person-specific sensitive data by encrypting them in the user data vault (User Registry) which allows configuration-based protection of sensitive PII. DIGIT requires additional registries to reference PII using this mechanism. In addition, registries in DIGIT can leverage its data protection (Signing and Encryption) core service to provide additional protection to registry-specific attributes.

Registry data in DIGIT can be signed for tamper-proofing using its signing and encryption core service. A proof of concept for this has already been done on the ePass module that was built on the DIGT platform. All key data modifications in DIGIT are access logged to provide an audit trail, which can be accessed through APIs. The upcoming version of DIGIT is planning to bring in the concept of immutable event logs to further strengthen this capability. DIGIT leverages open-source telemetry to provide the ability to gather telemetry data and extend it for the DIGIT-specific processing pipeline. This framework allows for additional event definitions and contextual extension of the telemetry processing pipeline thereby future-proofing this capability in DIGIT.

Reusability and Extensibility

DIGIT platform is designed as a collection of more than 50+ atomic microservices which are bundled together in a given context to provide end solutions. Microservices in DIGIT can be mainly categorized in three categories: Data services (Registries, reference Master data management, etc.), Tech infrastructure services (Authentication, authorisation, notification engine etc.) and domain services (Assessment, NOC etc.). Citizen, employee and administrative interfaces in DIGIT use these microservices to achieve the needed functionality.

Data models and APIs in DIGIT are defined as OpenAPI 3.0 specifications and can be extended by using a combination of configuration and extension techniques. E.g. if the additional attributes are only needed to be stored with format validation, it can be a simple schema extension, while if the additional business checks/functionality need to be implemented using the extended attributes then it can be achieved using pre/post request filters or extending underlying microservices.

DIGIT allows the extension of existing capabilities without needing architectural interventions. As described above extension of existing functionality on DIGIT can be achieved using additional configurations, additional extension services or request/response filters.

Several partners have extended DIGIT modules to cater to new use cases. For instance, DIGIT mCollect module caters to the collection of fees for more than 50 services on the counter, but it did not have a citizen interface for payment of these services online. Directorate General Defence Estates (DGDE) wanted to introduce this interface for the citizens of cantonment boards in India and were able to easily enhance the mCollect module to include this capability. Similarly, Punjab has reused several DIGIT core services to develop new modules on the platform with minimum effort.

DIGIT supports single-instance multi-tenancy to enable sharing of the underlying infrastructure, also all DIGIT data models and services are designed to be multi-tenanted.

DIGIT uses API first approach in its design and development to ensure loose coupling between its various components. These APIs are clearly defined using OpenAPI 3.0 specifications to ensure clear documentation.

Evolvability and Scale

As described above, the extension of existing functionality on DIGIT can be achieved using additional configurations, additional extension services or request/response filters. Similarly, new functionality can be added by re-bundling existing building blocks in the context of new use cases and implementing only additionally required services without requiring any architectural overhaul. Additionally due to its loosely coupled API-driven design DIGIT allows for new components to be implemented in the technology that is most useful for that use case.

API-driven, the microservices-based architecture of DIGIT enables its components to evolve separately. On DIGIT Individual components can evolve separately to enable the heterogeneous evolution of the system.

DIGIT uses SemVer 2.0 for versioning its microservices and interfaces. Semantic versioning is a formal convention for specifying compatibility using a three-part version number: major version; minor version; and patch. More details on this can be found at this link: https://semver.org/.

DIGIT is designed to be horizontally scalable. The microservices-based architecture of DIGIT also enables it to scale only needed components/services, thereby providing resource efficiency. E.g. Billing and Collection services can be scaled separately during financial year closing if the load pattern indicates an increasing volume of bill payments during that period.

DIGIT is designed to be hardware agnostic and can be run on any hardware. It has been tested on multiple commercial clouds and state-sponsored bare metal infrastructure. Components of DIGIT that need to use underlying hardware have been carefully chosen (in cases where DIGIT is using other open-source components) or designed (DIGIT’s own components) to provide a layer of abstraction that can be extended for any type of hardware.

Multi-channel Access

DIGIT is designed using API first approach, therefore enabling any user interface channel to leverage it. DIGIT’s own user interfaces (Web/mobile app, WhatsApp chatbot) are implemented using its APIs to ensure offered platform capabilities and data are accessible to any delivery channel based on configured policies. In states like Punjab and AP where DIGIT modules are being used, the citizens have been given multi-channel access - ULB counters, Web portals, Mobile App, WhatsApp Chatbot and 3rd party applications like Paytm, BBPS to avail local government services.

DIGIT’s access control mechanism can be configured to provide different levels of access based on channels and roles.

Ecosystem-driven

DIGIT platform and its user interfaces are completely open source. Also, all external components used in DIGIT are also Open Source. Due to its API-based and event-driven architecture DIGIT can be integrated with any existing stack. Wherever appropriate, DIGIT also provides out-of-the-box integrations with crucial stacks/platforms. The most common integrations are to payment gateways, SMS providers and SMTP email servers for a typical implementation.

More than 14 organizations have already partnered with us to implement DIGIT across multiple implementations in the country and have built more than 20 new solutions on top of the platform.

DIGIT also provides the capability to gather feedback from the ecosystem in a digital manner. Feedback capability in DIGIT can be looked at the following levels:

• Service Delivery feedback on services offered through DIGIT - DIGIT provides a highly configurable and extensible Public Grievance module to enable this kind of feedback/redressal for functional users (Citizens, employees etc)

• Service Usage feedback - DIGIT user interfaces include a telemetry SDK which is backed by telemetry infrastructure on the DIGIT platform. Coupled with API access logs, this enables DIGIT to gather user feedback through live action and can be used for fine-tuning interfaces and APIs

• Design/Feature feedback - As an open-source project on GitHub, DIGIT provides a mechanism to provide comments/feedback on its various components using GitHub. This feedback can be leveraged to create a Point of View on the future roadmap for the platform.

Overview

About page, FAQ and 3 new KPIs are added to the DSS page

Release Highlights

About page for the dashboard is added which helps users to understand the purpose, how data is secure and from where the data is being pushed.

And 3 new KPIs were added for administrative purposes.

Release Features

About page

FAQ

3 KPIS - Non-tax revenue collected, Non-tax revenue contribution % and Average PT collected.

Related Doc Links

DIGIT is India’s largest open-source platform for digital governance. It is built on OpenAPI (OAS 2.0) and provides API-based access to a variety of urban/municipal services enabling state governments and city administrators to provide citizen services with relevant new services and also integrate the existing system into the platform and run seamlessly on any commercial/on-prem cloud infrastructure with scale and speed.

Key Architecture Highlights

• DIGIT is a microservices-based platform that is built to scale. Microservices are small, autonomous and developer-friendly services that work together.

• A big software or system can be broken down into multiple small components or services. These components can be designed, developed & deployed independently without compromising the integrity of the application.

• Parallelism in development: Microservices architectures are mainly business-centric.

• MicroServices have smart endpoints that process info and apply logic. They receive requests, process them, and generate a response accordingly.

• Decentralized control between teams, so that its developers strive to produce useful tools that can then be used by others to solve the same problems.

• MicroServices architecture allows its neighbouring services to function while it bows out of service. This architecture also scales to cater to its clients’ sudden spike in demand.

• MicroService is ideal for evolutionary systems where it is difficult to anticipate the types of devices that may be accessing our application.

Multi-layer Architecture

DIGIT follows Multilayer or n-tiered distributed architecture pattern. As seen in the illustration above there are different horizontal layers with some set of components eg. Data Access Layer, Infra Services, Business Services, different modules layers, client Apps and some vertical adapters. Every layer consists of a set of microservices. Each layer of the layered architecture pattern has a specific role and responsibility within the application.

• Layered architecture increases flexibility, maintainability, and scalability

• Multiple applications can reuse the components

• Parallelism

• Different components of the application can be independently deployed, maintained, and updated, on different time schedules

• Layered architecture also makes it possible to configure different levels of security to different components

• Layered architecture also helps users test the components independent of each other

to learn more about the setup basics.

Learn how to configure the DIGIT Urban platform. Partner with us to enhance and integrate more into the platform.

All content on this page by is licensed under a .

Introduction

An Urban Local Body (ULB) is defined as a tenant. The information which describes the various attributes of a ULB is known as tenant information. This detail is required to add the ULB into the system.

Data Table

Procedure

Data Definition

Steps to fill data

1. Download the data template attached to this page.

2. Have it open and go through all the headers and understand the meaning as given in this document under section 'Data Definition'.

3. Make sure all the headers, its data type, field size and its definition/ description are understood properly.

4. In case of any doubt, please reach out to the person who has shared this document with you and discuss the same to clear out the doubts.

5. Start filling the data starting from serial no. and complete a record at once. repeat this exercise until the entire data is filled into a template.

6. Verify the data once again by going through the checklist by taking care of each and every point mentioned in the checklist.

Checklist

The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity. There are no checklist activities exists which are specific to the entity.

Attachments