1 of 100

v2.8

Introducing DIGIT Urban

The Digital Urban Governance Platform

Mission

Building an urban governance platform to catalyze digital transformation across towns and cities - changing the way citizens interact with government bodies.

Overview

DIGIT Urban Stack is a set of Open APIs, services, and reference implementations, set up as a public good, to allow government entities, businesses, startups, and civil society to use a unique digital Infrastructure and build solutions for urban India at a large scale. It provides a set of open standards, specifications and documentation to create a level playing field and enable ecosystem players to innovate on the stack. As a public good, the platform is provided without profit or restriction to all members of society.

Important Updates:

DIGIT is certified as a Digital Public Good (DPG) by the Digital Public Goods Alliance (DPGA) - a multi-stakeholder initiative with a mission to accelerate the attainment of sustainable development goals. Find the DIGIT platform in the DPG registry along with a host of other globally recognized DPGs.

Click here for more details.

Goals

The urban mission offers digital governance solutions that encapsulate the core platform principles. The apps provide

Secure & reliable governance tools
Simple reusable modules for effective integration
Scalable & standardized solutions
Open APIs to promote interoperability
Multiple channel support
Configurable building blocks that support customization at each stage

Approach

DIGIT-Urban focuses on inclusion and is designed on the principle of enhancing both platform openness and choice for citizens. The platform uses open APIs and standards, creating a powerful framework to drive convergence across the multiple systems currently in use and to lower the barrier to entry for locally-developed solutions.

Keeping in mind that most Indians use the internet through their phones, we follow and advocate a “mobile-first” approach, while supporting multi-channel access to accommodate diverse needs and preferences.

Open Source - DIGIT is Open Source and has been built using the best in class Open Source technology stacks powering the most advanced companies in the world. DIGIT is able to provide the lowest total cost of ownership and helps ensure that governments retain strategic control of their systems and data.
Mobile-Enabled - DIGIT has adopted a mobile-first approach, with robust mobile applications enabling citizens to easily access government services through their phones. Government officials and field workers are also empowered with mobile applications that enable them to deliver 24×7 governance with ease.
Real-time Dashboards - DIGIT’s real-time dashboards provide governments with actionable insights on demand. Administrators and department heads are empowered with verified data that enables them to manage their work and budgets better. Field-level employee reports enable effective performance management and ensure efficient usage of government resources.

Useful Links

Contact Us

Platform

Master Migration Document

2.8 release master migration document

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

Note : Replace the existing persister files with the latest files linked above.

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
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
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 -

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.

MDMS Configuration & Service Build Updates

Configuration changes and service build details

MDMS Changes

Config Changes

Service Build Updates

Product Release Notes

Master Migration Document

2.8 release master migration document

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

Note : Replace the existing persister files with the latest files linked above.

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
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
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 -

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.

Implementation Checklist

@Sl No

Checklist

Yes/No/Partially

Reference link

Owner

Date(mm/dd/yyyy)

Remarks

Product Release Notes

Yes

Kavi

We are not doing migration of data for PT and W&S module as privacy is disabled by default.

List of services that needs to be upgraded

Yes

Kavi

Verified.

List of SMS template changes

Kavi

Not provided

Verify Configs, MDMS, devOps Changes

Yes

Kavi

Verified

Verify test cases for all enhancements/updates

Yes

Gurjeet/Neha

No test case available for :

OBPS Tabular Reports in old UI/UX
National Dashboard Adaptor Integration Testing
Enhance DSS to drive adoption by state leadership - Work on enhancements share by PMIDC team

Verify list of issues reported by partners

Vinoth/Pradeep

Not added in release doc.

Verify performance testing report

Yes

Gurjeet/Neha

No report found

Verify backward compatibility testing report

Yes

Gurjeet/Neha

More than 40% test cases failing from v2.6 and v2.7

Frontend and Backend code merge

Yes

Vinoth/Chinmay/Gurjeet

Verified developer guide and airflow adapter code.

Increase semversion,Prepare builds from UPYOG Code base and Deploy

Vinoth/Chinmay/Gurjeet

Upgrade Upyog UAT plan

Yes

Vinoth/Chinmay/Gurjeet

Loading the localisation codes in UAT

Yes

Gurjeet/Neha

Prepared scripts

Backward compatibility testing passed

Navyashree/Kavi

Backward compatibility tested using API’s

List of bugs identified by Impl Team(Known issues)

Impel Team

Regression in UPYOG-UAT environment

Gurjeet/Neha

Functional Sign off on UPYOG UAT

NIUA Team /Ajay

FMS integration testing with UPYOG UAT

NIUA Team /Ajay

Take go ahead from the Program Team

Pradeep/Ajay

Confirmation for production code merge

Pradeep/Ajay

Verify Localization changes

Yes

Gurjeet/Neha

Deployment steps on UPYOG Production

Vinoth/Gurjeet

Upgrade Upyog documentations

Ajay

Testing/Sanity on UPYOG production

Gurjeet/Neha

Production Sign-off

Yes

NIUA Team /Ajay

State dashboard/national dashboard testing

Gurjeet/Neha

Builk bill generation and performance testing

Kavi

Rollback Plan

Yes

Pradeep

Staging upgradation plan

Pradeep/Vinoth

After upyog upgradation, will start this task after getting confirmation from marketing team.

Compare code with security audit : Verify whether similar errors possible because of new code changes

Kavi/Engineering team

Push images required by new UI changes to s3 bucket and update tenant.json

Pradeep/NIUA

Verify changes required in hardware/AWS/space issues for upgradation

Yes

Pradeep/Vinoth

Kavi

Increase memory in pdf service to support bulk bill generation. Increase heap memory for filestore service. Max filesize allowed to be verify. Increase pdf service replica based on client requirement.

Apk referring to UAT to be publish for new UI. The same verified by Tester

@JaganKumar

NIUA

Release Notes

New release features, enhancements, and fixes

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

Feature

Description

Water & Sewerage UI/UX Revamp

Employee W&S UI/UX revamp
Citizen UI/UX revamp

Water & Sewerage disconnection

Added W&S disconnection feature:

Apply for disconnection (Permanent/Temporary)
Proceed with the workflow and Execute disconnection.
Events and Notifications for each step

Added new screens for disconnection workflow.

Privacy Exemplar -

Added Data Privacy for water & sewerage for masking/unmasking PII data.

W&S Bill Amendment Workflow update

Code change in billing service, workflow change and data update in workflow transition table.

New KPIs for National Dashboard

Bill amendment UI/UX revamp

Enhancements

Updated Feature

Description

Enhancements in National Dashboard- FAQ & About

Updated - About, Purpose page for National Dashboard

B&D Tabular Reports - in old UI/UX

Added - Birth Count Report, Death Count Report, Birth Count Report by District, Death Count Report by District, Birth and Death Certificate Payment Report.

Bill amendment UI/UX revamp

Search Amendment
Create a new Amendment for W&S
Inbox screen for bill-amendment

Notification based on channels - PGR, OBP and mCollect

Enhanced PGR, OBPS and mCollect notifications to incorporate different notifications based on Channels.

Bulk Bill PDF Generation and Performance Testing

Updated _jobscheduler API for enhancing performance for bulk records.

TL Tabular Reports in old UI/UX

Enhanced TL Report: TLDailyCollectionReport, TLApplicationStatusReport, TradeLicenseRegistryReport

Navigation re-direction from new UI to old UI

Added W&S reports: Receipt Register, Collection Register, Defaulters Report.

Bill Genie UI/UX revamp

Added:

Search bills
Group bills
Download bills

National Dashboard Adaptor Integration Testing

Airflow setup for all modules integrated all modules with an adapter.

OBPS Tabular reports in old UI/UX

Enhanced OBPS Report: OBPS Daily Collection Report

Survey

Create surveys, update surveys, view survey results, fill in survey forms.

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:

Metric

Description

Estimate

Time to Value

Time taken from Gate 2 to all features of DIGIT 2.8 to be released as part of UPYOG 2.0

1.5 months

No. of states using the feature

No. of states implementing the feature/module within next 6 months

Refer Account Wise Feature Demand

No. of ULBs using the feature

No. of ULBs implementing the feature/module within next 6 months

Refer Account Wise Feature Demand

Frequency of Use(Survey)

No. of Surveys completed in next 6 months

Target: 3

‌Document Resources and Links

UI Technical Documents

Updated docs

Trade License - Apply Flow
New Trade License Application

Backend Service Documents

Program Roll Out Plan

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

Account Wise Feature Demand

Accounts

No. of ULBs

Current Version

Features to be use from digit 2.8

Expected Timeline

UKD

Digit 2.5

TL Reports , bulk bill generation

Q1 2023-24

PUNJAB

166

Digit 2.2

Finance rollout dashboard, TL Reports , bulk bill generation

Q1 2023-24

ODISSA

114

Digit 2.3

Finance rollout dashboard, TL Reports , bulk bill generation

Client decision on upgrade

NIUA- UPYOG

Digit 2.7

All features of digit 2.8 , build APK and publish

March 27th

NIUA-Kerala

Digit 2.7

All features of digit 2.8

Client decision on upgrade

Partners(e.g. BEL)

As per demand

Partners' decision to update

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.

Module

Feature

Partner User*

Timeline

B&D

B&D Tabular Reports - in old UI/UX

Kerala

To be decided by partner

Data Privacy

PII, data masking

To be Decided

To be decided by partner

OBPS

OBPS Tabular Reports in old UI/UX

Haryana, Chhattisgarh

To be decided by partner

Platform

Bill Genie UI/UX revamp

To be decided by partner

Platform

Bill amendment UI/UX revamp

To be decided by partner

Platform

Help/FAQ section in Citizen UI - common framework

To be Decided

To be decided by partner

Platform

Citizen survey feature

To be Decided

To be decided by partner

TL Tabular Reports in old UI/UX

Kerala

To be decided by partner

W&S

Disconnection Notice (With Reason)

Chhattisgarh

To be decided by partner

W&S

Closure (Permanent/Temporary)

Chhattisgarh

To be decided by partner

W&S

Payment/ Billing History

Chhattisgarh

To be decided by partner

W&S

W&S UI/UX Revamp

Chhattisgarh

To be decided by partner

W&S

W&S disconnection

Chhattisgarh

To be decided by partner

W&S

W&S Privacy Exemplar

Chhattisgarh

To be decided by partner

W&S

Standard Reports for WnS - Receipt Register, Collection Register, Defaulters Report - in old UI/UX

Chhattisgarh

To be decided by partner

*As per current demand from NUDM-enabled states

Adoption Metrics

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

Metric

Description

Estimate

Time to Value

Time taken from Gate 2 to all features of DIGIT 2.8 to be released as part of UPYOG 2.0

1.5 months

No. of states using the feature

No. of states implementing the feature/module within next 6 months

Refer Account Wise Feature Demand

No. of ULBs using the feature

No. of ULBs implementing the feature/module within next 6 months

Refer Account Wise Feature Demand

Frequency of Use(Survey)

No. of Surveys completed in next 6 months

Target: 3

Platform Features

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:

Key Principles

Description

Interoperability

DIGIT is designed as an API-first platform and with Open APIs & Open Standard interoperability is maintained.
Along with this, taxonomies are available for the key domain entities/registries on DIGIT.

Data privacy and security by design

Data privacy and security design are a very critical part of the design of DIGIT.
Core service layer of DIGIT includes a signing and encryption service that provides capabilities to sign/encrypt/mask sensitive data.
Appropriate access controls can be defined in the APIs to ensure authorised access to sensitive data

Transparency and Accountability through data

DIGIT has

The capability to define registries, preferably through standard specifications like OpenAPI 3.0
The capability to configure registry attributes for security and protection as per the configuration.
Mechanisms to verify data and its provenance through audit logs (access and changelogs), preferably through APIs.

Reusability and Extensibility

The DIGIT platform is designed as a collection of more than 55+ atomic microservices which are bundled together in a given context to provide an end solution.
DIGIT allows the extension of existing capabilities without needing architectural interventions.
Components are designed to be independently reusable without any tight coupling.

Evolvability and Scale

On DIGIT:

Capabilities can be added without needing overall system re-architecture.
Individual components can evolve separately to enable heterogeneous evolution of the system.
Scaling can be done horizontally to handle changes in request volumes.
Individual components can be scaled independent of each other, to enable efficient resource utilisation

Multi-channel access

DIGIT allows multiple channels of solution delivery - ULB counters, Web portals, Mobile App, WhatsApp Chatbot and 3rd party applications like Paytm, tablets, etc.
DIGIT’s access control mechanism can be configured to provide different levels of access based on channels and roles.

Ecosystem-driven

DIGIT leverages open source technologies to reduce the cost of solutions.
Leverages or integrates with or extends existing platforms/stacks like IndiaStack, IUDX, ICTRA infrastructure etc.
Provides the capability to gather feedback from the ecosystem in a digital manner.

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.

Email Account Configuration

Introduction

An email account of the client/state team has to be set up in order to receive/send the email notifications.

In order to achieve the functionality, an email account has to be set up at there server since most of the states would defer from creating an account with the Gmail/public server. Further, this email account has to be integrated with the various DIGIT modules.

Data Table

In order to achieve the above functionality, we require the below-mentioned details

Sr. No.

Email ID

Your Name

Account Type

Incoming Mail Server

Outgoing Mail Server (SMTP)

Password

Incoming Server POP3 Port

Outgoing server SMTP Port

Encrypted Connection Type

Days after which the email should be removed from the server

Bihar

POP3

SMTP

****

192.172.82.12

Auto

The values mentioned here are sample data.

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory?

Description

Email ID

Alphanumeric

N/A

Yes

Email id which is being configured

Your Name

Text

256

Yes

The name on behalf of which the email would be sent in order to receive the updates

Account Type

Alphanumeric

Yes

The type of email account type protocol which will be used to download messages

Incoming Mail Server

Numeric

(12,2)

Yes

The IP address of the email server through which messages would be received

Outgoing Mail Server(SMTP)

Numeric

(12,2)

Yes

The IP address of the email server through which messages would be sent

Password

Alphanumeric

Yes

The password of the email server

Incoming Server POP3 Port

Numeric

(12,2)

Yes

The port number through which the emails are received

Outgoing server SMTP Port

Numeric

(12,2)

Yes

The port number through which the emails are to be sent

Encrypted Connection Type

Alphanumeric

Yes

The encryption type which is used for the connection

Days after which the email should be removed from the server

Numeric

(12,2)

Yes

The number of days after which the email should be deleted from the server (not from the local device)

Steps to fill Data

Below steps could be followed in order to fill the template:

Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Ask the state to gather all the data related to the technical configuration from the email server settings.
Get the attached template filled from the state and a sample data is provided in the data table section for reference.
The data would be available in the POP and IMAP account settings at the server level.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.

Checklist

The checklist is a set of activities to be performed one 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.

Sr. No.

Checklist Parameter

Example

Make sure that each and every point in this reference list has been taken care of

Entity Specific Checklist

Not Applicable

Attachments

Payment Gateway Configuration

Introduction

DIGIT has modules which require the user to pay for the service that he/ she is availing for example property tax, trade license etc. . In order to achieve the functionality, we have a common payment gateway developed which acts a liaison between DIGIT apps and external payment gateways (which depends on the client requirements).

This module facilitates payments and lookup of transaction status.

Data Table

Following are the details required from the payment gateway vendor in order to configure the payment gateway:

Sr. No

Integration Kit

API Documentation

Redirect Working Key

Merchant Id

Test credential of Debit Card/ Net banking

File Name

XYZ#123

UDDUK

File Name

Data given in the table is a sample data.

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory?

Definition/ Description

Integration Kit

Document

Yes

This is a document that is sent by the vendor which contains information on how to integrate the service

API Documentation

Document

Yes

This is a separate document which is sent by the vendor in order to help ideally helps us to retrieve the transaction status

Redirect Working Key

Alphanumeric

Yes

The working key is provided by the vendor for the generation of the redirection URL

Merchant Id

Alphanumeric

Yes

Merchant id provided by the vendor

Test credential of Debit Card/ Net Banking

Document

Yes

These are the details of the debit/credit card or net banking credentials which would help us test the gateway

This contains the card number/Code/Account number etc.

Steps to fill data

The payment gateway is a vendor oriented service that is integrated with different modules in order to facilitate the transactions. Below mentioned are the steps which are followed:

The client has to finalize a payment gateway vendor (for example PAYU, Paytm, HDFC, AXIS atc.) depending upon the requirements.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
After which the details/ documents mentioned in the template would be provided by the vendor.
These details are to be received separately for both prods as well as UAT.
Get the IP address for UAT and Production environments whitelisted from the vendor.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

Common Checklist

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

Sr. No.

Checklist Parameter

Example

Make sure that each and every point in this reference list has been taken care of

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Sr. No.

Checklist Parameter

Example

While finalizing a payment gateway vendor make sure that the vendor should support transactions into multiple bank accounts based on the key( which would be tenantid)

Do get the details for both the environments separately i.e UAT and Production

Attachments

Boundary Hierarchies

Introduction

A ULB is divided into certain categories of boundaries by ULB administrative authorities in order to carry out ULB’s functions better. A ULB/City could be divided by a different set of delimitation of boundaries based on functions as given below.

Revenue - Delimitation of ULB into boundaries to perform the target setting and collection of revenue.
Administration - Delimitation of ULB into boundaries for the better administration of ULB.
Locality/ Location - Delimitation of ULB into boundaries based on the places known to citizen with names and easily identifiable by the common person.

All these authorities have designated certain levels of boundary classification for a certain ULB.

Data Table

The below mention table is used to collect data for the types of hierarchy being followed:

Sr. No.

Code*

Boundary Hierarchy Type*

Description

ADM

Administration

Administration level boundary classified on the basis of administrative functions such as scrutinize certain rules and regulations

REV

Revenue

Revenue-based classification of a ULB is done on the basis of revenue collection

LOC

Locality

Location-based classification could be done in order to identify a certain place. For example, Locality of a house of a citizen could follow the below hierarchy:

House no.
Mohalla
Area
Ward
City

The above-mentioned data for the boundary hierarchy is sample data.

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory?

Definition/ Description

Code

Alphabet

Yes

Code is used to identify a certain classification of the type of boundary hierarchy

Boundary Hierarchy Type

Alphanumeric

256

Yes

The meaningful name to define one group of boundaries defined to perform one function

Description

Alphanumeric

256

Yes

A brief description of the boundary hierarchy

Steps to fill data

Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Identify all the types of boundaries which are being used in the state in order to carry out various administrative/revenue functions.
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.
Then fill up the hierarchy types and the codes in the respective columns in the template.
Code should be created for the type of boundary being classified.
A brief description of the boundary hierarchy type would be helpful.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.

Checklist

Common Checklist

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

Sr. No.

Checklist Parameter

Example

Make sure that each and every point in this reference list has been taken care of

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Sr. No.

Checklist Parameter

Example

Make sure that the hierarchies types should be uniform across all the ULB’s /cities in the state

Only 3 types of boundary hierarchies are allowed

Attachments

ULB Bank Accounts

Introduction

It is a ULB bank account which is operative at least to receive or deposit the day to day revenue collection done by the ULB. It is used by online payment integrator to disburse the amount in ULBs accounts which have been collected through a payment gateway into a pool account managed by the payment gateway.

Data Table

Below given data table represents the excel template attached. Data given in the table is a sample data.

Sr. No.

Code*

ULB Name*

Bank Name*

Branch Name*

Account Number*

Account Type*

IFSC*

dehradun

Dehradun Municipal Corporation

SBI

Rajpur

XXXX0082XX01

Saving

SBIX0921

haridwar

Haridwar Municipal Corporation

PNB

Chauk

XXXX9820XX9

Saving

PNBX8320

Data given in the table is sample data.

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory

Definition/ Description

Code

Alphanumeric

Yes

Unique code is given to the bank detail record e.g. dehradun

ULB Name

Text

256

Yes

Name of Urban Local Body

Bank Name

Text

256

Yes

Name of the bank where the account exists

Branch Name

Text

256

Yes

Name of the bank branch where the account exists

Account Number

Alphanumeric

Yes

Bank account number to be used to transfer the amount

Account Type

Text

256

Yes

Account type. e.g. Saving, Current etc.

IFSC

Alphanumeric

Yes

IFS code of branch as per FBI guidelines

Steps to fill data

Download the data template attached to this page.
Have it open and go through all the headers and understand the meaning of them by referring 'Data Definition' section.
Make sure all the headers, its data type, field size and its definition/ description is understood properly. In case of any doubt, please reach out to the person who has shared this document with you to discuss the same and clear out the doubts.
Identify the bank account which is to be used to transfer the amount which is collected online for various services.
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.
Verify the data once again by going through the checklist and taking care of each and every checklist point/ activity mentioned in the checklist.

Checklist

The checklist is a set of activities to be performed after 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.

To see the common checklist refer to the page Checklist consisting of all the activities which are to be followed to ensure complete and quality data.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Sr. No.

Activity

Example

Code should not consist of any special characters

E.g. dehradun is allowed but dehradun@1 is not allowed

The account number should not consist of any special characters.

As issued by the bank

Attachments

Cross Hierarchy Mapping

Introduction

This is the 3rd step that comes after the boundary data collection. Cross hierarchy mapping happens in case a child has a relationship with more than 2 parents. This double relationship between the child and parents could happen between different hierarchies as well.

For example: In Admin level boundary hierarchy a mohalla M1(child) could be a part of 2 Wards(parent) W1 and W2. In such a case a single Mohalla(child) has to be mapped to 2 Wards(parent).

Data Table

Below is the data table for the Boundary:

Hierarchy Type

Hierarchy Type 1*

Hierarchy Type 2*

Sr.No

Boundary Type*

Boundary Code*

Boundary Type*

Boundary Code*

Ward

Mohalla

Ward

Mohalla

Ward

Mohalla

Ward

Mohalla

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory?

Definition/ Description

Hierarchy Type 1

Text

256

Yes

Hierarchy Type 2

Text

256

Yes

Boundary Type

Text

Yes

Boundary Code

Alphanumeric

Yes

Boundary Type

Text

Yes

Boundary Code

Alphanumeric

Yes

Steps to fill data

Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Firstly Identify all the child levels which have a relation with more than 2 parent boundary types and their hierarchy types as well.
Fill up the boundary hierarchy (names/ codes) types in place of boundary type 1/2.
Then along with the codes start filling in one by one with the proper mapping between every child and parent.
The Sr. No should be in an incremental order for every new child level.
Prepare a new table for every different parent-child relation.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.

Checklist

Common Checklist

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

Sr. No.

Checklist Parameter

Example

Make sure that each and every point in this reference list has been taken care of

Entity Specific Checklist

This checklist covers the activities which are specific to the entity. There is no entity-specific checklist activity applicable here.

Attachments

Boundary Data

Introduction

This is the next step after collating all the boundary hierarchies which are being used in the state. In a hierarchy, there are certain types of boundary classification and in all the levels there will be a mapping which we could define as a parent-child mapping in order to link certain levels of the classification.

For example, a hierarchy could be:

Administration Hierarchy: City/ULB → Zone → Ward → Locality

In the above-mentioned hierarchy, a City/ULB is being divided into different into zones followed by zones into wards and at the end wards into the locality.

Data Table

Data has to be collected for every boundary hierarchy type and boundary type with a mapping between the boundary code and its parent boundary code. Following is the table which is to be used across all the hierarchy types.

Sr. No.

Boundary Code*

Boundary Name* (In English)

Boundary Name* ( In Local Language)

Parent Boundary Code*

Boundary Type*

Hierarchy Type Code*

Ward no.1

वार्ड नंबर 1

Ward

ADM

Ward no.2

वार्ड नंबर 2

Ward

ADM

Ward no.3

वार्ड नंबर 3

Ward

ADM

Ward no.4

वार्ड नंबर 4

Ward

ADM

Data given in the table is a sample data.

Procedure

Data Definition

Following is the definition of the data columns which are being used in the template:

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory?

Description

Boundary Code

Alphanumeric

Yes

This is a code for the sub-classification for a particular boundary. Should be unique across all boundaries defined

Boundary Name (In English)

Text

256

Yes

The name of the boundary that is being defined in the English language

Boundary Name (In Local Language)

Text

256

Yes

The name of the boundary that is being defined in the local language of the state e.g. Telugu, Hindi etc.

Parent Boundary Code

Alphanumeric

Yes

This is the boundary code of the parent which identifies to which parent the child belongs to

Boundary Type

Text

256

Yes

The name of the boundary type i.e. Ward, Zone etc.

Hierarchy Type Code

Alphanumeric

Yes

Steps to fill data

Following are the steps which should be used to fill the template:

Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
After Identifying all the boundary hierarchy, get the sub-classification of all the hierarchies.
Figure out the codes for all the sub-classification for a particular city/ULB.
Start filling the template from the top of the hierarchy in a drill-down approach.
A parent-child mapping code has to be created for every boundary level except for the top level.
Follow the steps until you reach the last sub-classification.
Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.

Checklist

Common Checklist

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

Sr. No.

Activity

Example

Make sure that each and every point in this reference list has been taken care of

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Sr. No.

Activity

Example

Every boundary type of data should be filled separately

Attachments

Receipt Format

Introduction

Tax is levied by the government in certain brackets, i.e there are certain components of a tax which sum up and make the final trans-actionable amount. For example, a property tax could have swatch-ta tax, fire cess and certain other components which sum up and make a final amount.

Data Table

Sr. No.

Code*

Service*

Category*

Name*

Is Debit*

Is Actual Demand*

Order*

PT_UNIT_PENALTY

Penalty

PT Penalty

FALSE

PT_UNIT_EXEMPTION

Exemption

PT Exemption

TRUE

Data given in the table is sample data for reference.

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory?

Description

Code

Alphanumeric

Yes

The code for the tax that is being levied

Service

Text

256

Yes

This is the module or the name of the service for which the tax head is being mentioned

Steps to fill data

Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Get all the tax heads for a particular module and then proceed to the next module.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

The checklist is a set of activities to be performed on 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.

Sr. No.

Checklist Parameter

Example

Make sure that each and every point in this reference list has been taken care of

Entity Specific Checklist

Not Applicable

Attachments

Workflow Process

Introduction

The workflow process is a set of steps through which information flows in sequence and the workflow roles which derives the actors are assigned to a step to complete the work defined for that level. The states of each level are derived based on the information received from the previous step.

Data Table

Sr. No.

Current State

Workflow Actions

Next State

Role Name

SLA

Create and Approve

Approved

Assistant

Forward

Pending for Approval

Assistant

Pending for Approval

Verify and Approve

Approved

Supervisor

Pending for Approval

Save

Pending for Approval

Supervisor

Pending for Approval

Reject

Rejected

Supervisor

Pending for Approval

Send Back to Assistant

Rejected for Review

Supervisor

Rejected for Review

Forward

Pending for Approval

Assistant

Rejected for Review

Cancel

Rejected

Assistant

Data given in the above table is sample data.

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory?

Definition/ Description

Current State

Text

256

Yes

The Current State indicates the stage at which the process of the workflow in progress

Action

Reference

Yes

The Action indicates the activity that can be performed at the respective stage in the workflow. This refers to Workflow Actions

Next State

Text

256

Yes

The Next State is the state in the workflow that gets updated to in the respective stage on performing the action. (Example: assigning the for approval from one person to next person)

Role Name

Reference

Yes

The role is the different hierarchy of people with designation who are authorized to initiate, approval or rejecting the process. It refers to Workflow Levels

SLA

Integer

The SLA indicates the time-frame within which the action to be completed

Step to fill data

Download the data template attached to this page.
Have it open and go through all the headers and understand the meaning of them by referring 'Data Definition' section.
Make sure all the headers, its data type, field size and its definition/ description is understood properly. In case of any doubt, please reach out to the person who has shared this document with you to discuss the same and clear out the doubts.
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.
Verify the data once again by going through the checklist and 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.

Sr. No

Checklist Parameter

Example

Make sure that each and every point in this reference list has been taken care of

Entity Specific Checklist

Please discuss with a relevant department head before finalizing the workflow.

Attachments

Tax Heads

Introduction

Data Table

Sr. No.

Code*

Service*

Category*

Name*

Is Debit*

Is Actual Demand*

Order*

PT_UNIT_PENALTY

Penalty

PT Penalty

FALSE

PT_UNIT_EXEMPTION

Exemption

PT Exemption

TRUE

Data given in the table is sample data for reference.

Procedure

Data Definition

Sr. No.

Column Name

Data Type

Data Size

Is Mandatory?

Description

Code

Alphanumeric

Yes

The code for the tax that is being levied

Service

Text

256

Yes

This is the module or the name of the service for which the tax head is being mentioned

Steps to fill data

Download the data template attached to this page.
Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.
In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.
Get all the tax heads for a particular module and then proceed to the next module.
Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

Common Checklist

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

Sr. No.

Checklist Parameter

Example

Make sure that each and every point in this reference list has been taken care of

Entity Specific Checklist

Not Applicable

Attachments

Workflow Actions

Introduction

Workflow action defined as an activity which is performed by a workflow user on a service request/ application during the workflow. All the workflow actions are predefined and performed a well-defined job once performed.

In its nature actions are not configurable, only the localization of actions is permissible as a configuration.

Data Table

S. No.

Action

Description

Module(s)

Initiate

The action will start the application for citizen and CEMP