Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
This document describes various users of the HCM system and lays out the processes to manage the access and provisioning related aspects. Broadly, the users can be categorised as permanent users of the HCM system who will be identified by their individual usernames and passwords, and the users who will be provisioned in the system for temporary durations and identified by the codes assigned (henceforth referred to as coded users). The user management module of the HCM platform will provide the interface to create and manage all types of users.
User type
Role mapping in DIGIT
What they will do
Organization
Type of access
Supervisor-National
Dashboard user at the central level
Use the dashboard at national level, that is, all the provinces
NMCP
Web user
Supervisor-Provincial
Dashboard user at the provincial level
Use the dashboard at the provincial level, that is, their individual provinces
NMCP
Web user
Supervisor-Provincial
Dashboard user at the district level
Use the dashboard at the district level
NMCP
Web user
Supervisor-Local Monitors
Dashboard user at the village level
Supervisor to field teams
Temporary workers
Mobile app
Registradors
Registrar
Part of distribution teams
Temporary workers
Mobile app
Warehouse users-National
Warehouse manager role but tagged with the national boundary
Keep stock of inventory for the facility they are managing
Temporary workers
Mobile app
Warehouse- Provincial
Warehouse manager role but tagged with the provincial boundary
Warehouse-District
Warehouse manager role but tagged with the district-level boundary
Warehouse-Community
Warehouse manager role but tagged with the community-level boundary
Logistics-They ship material between warehouse and teams, that is, the movement of stock
In terms of the actions they are performing, they are the same as warehouse managers
Helpdesk users (L1, L2)
Access to the complaints inbox based on their level
Take, resolve, reject or escalate technical queries from different users
CHAI country team
Web user
Temporary users provisioned for UAT with different role action mappings
NMCP
Access based on their roles
Temporary users provisioned for trainings with different role action mappings
NMCP
Access based on their roles
Supervisors at Central, Provincial and District levels
Information is sent from NMCP to CHAI for provisioning via email.
CHAI provisions the users and sends the list of created users back to NMCP.
Local monitors
CHAI sends the list to eGov before the campaign for bulk provisioning.
eGov will send the list to CHAI after provisioning with codes and defaulted passwords.
During the campaign, CHAI helpdesk will provision the new LM (if any) using the DIGITs user management UI.
These will be deactivated from the system once the campaign ends based on inputs from CHAI team.
Note : All the communication to be on emails.
Registrars
CHAI sends the list to eGov before the campaign for bulk provisioning.
eGov team will do the bulk provisioning using backend APIs.
eGov will send the list of created users to CHAI after provisioning with codes and defaulted passwords.
During the campaign, CHAI helpdesk will provision the new LM (if any) using the DIGITs user msanagement UI one by one.
These will be deactivated from the system once the campaign ends based on inputs from CHAI team.
Warehouse users
Information is sent from NMCP to CHAI for provisioning.
CHAI provisions the users and send the list of created users back to NMCP.
Helpdesk staff: With system admin functionality
CHAI sends the list to eGov before the campaign for bulk provisioning.
eGov will send the list to CHAI after provisioning with codes and defaulted passwords.
Temporarily provisioned users for UAT/Training
CHAI will send the list of users to eGov a week before the UATs/training for provisioning into the system.
eGov will send the list to CHAI after provisioning with user names and passwords.
These will be deleted once the UAT/training is over.
For all kinds of users , the password reset would be managed by the system admin, who will be a part of the helpdesk.
Users who have forgotten their passwords would reach out to the helpdesk on the designated helpline number and request for a new password.
System admin would reset their passwords using a two-factor authentication. The email ID for retrieving the passwords would be the same for all users and would be managed by the system administrator.
The system administrator would regenerate the password and communicate to the users over a phone call or in a Whatsapp group.
This would be as per the Master Data template.
A username, once created during user creation, must not be changed.
- Regarding the use of special characters: It is recommended that only commonly known special characters like period (.) be used in the username to make it easy to remember
- Regarding use of the capital case: It is recommended to use either all lowercase or all uppercase characters to make it easy for users to remember and enter the login credentials (lowercase preferred).
- It is recommended to keep passwords simple (and defaulted to a single value/string) so that mobile app users do not forget the password, and hence, do not face a barrier in using the app.
It has been assumed that user creation for temporary users who keep changing during the campaign would be taken care of by the helpdesk team.
Password
Password to log in to the system
Yes
Password is encrypted and not retrievable from the system. Password format to be decided.
Name
The name of the user who wants to access to the system
Yes
Mobile number
Mobile number of the user
No
Gender
Gender of the user being registered
Yes
Date of Birth
Date of birth of the user being registered
Yes
Email ID of the user being registered
Yes
Email used for password recovery using OTP-based authentication.
Correspondence Address
Address of the user being registered
No
Role
Role assigned to the user to enable her to carry out her tasks and access required data and services
Yes
Supports multiple role assignments.
Employment Type
The employment types indicate the type of contract which he/she holds within the organisation. This indicates whether he/she is a permanent employee, or a contract employee for a short period. Either one in the employment type - “Permanent”, “Temporary”, “DailyWages” and “Contract” - should be selected
Yes
Date of Appointment
Date the user is hired
No
Sr. No
Sequence number for the list
Boundary hierarchy type
The meaningful name to define one group of boundaries tasked to perform one function
Mandatory
MDMS
String
Yes
Code
Code is used to identify a certain classification of the type of boundary hierarchy
Mandatory
MDMS
String
Yes
Description
A brief description of the boundary hierarchy
Mandatory
MDMS
String
Yes
Facility Name
Identifier of the facility
Yes
Is Permanent
Is the facility permanent or temporary
Yes
Facility Type
What is the facility used for? Example, warehouse, community, health centre
Yes
Address
Yes
Administrative Area
Administrative boundary of the facility
Yes
Address Line 1
No
Address Line 2
No
Landmark
No
City
No
Pincode
No
Building Name
No
Street
No
Storage
Storage capacity of the facility
No
Facility Name
Is permanent
Facility type
Administrative area
Address line 1
Address line 2
Landmark
City
Pincode
Building Name
Street
Storage
Solimbo District Warehouse
Yes
Warehouse
Solimbo
Sr. No.
Boundary Code*
This is a code for the sub-classification for a particular boundary. Should be unique across all boundaries defined
Mandatory
MDMS
String
Yes
Boundary Name* (In English)
The name of the boundary that is being defined in the English language
Mandatory
MDMS
String
Yes
Boundary Name* (In Local Language)
The name of the boundary that is being defined in the local language of the state e.g. Portuguese, Hindi etc.
Mandatory
MDMS
String
Yes
Parent Boundary Code*
This is the boundary code of the parent which identifies to which parent the child belongs to
Mandatory
MDMS
String
Yes
Boundary Type*
The name of the boundary type i.e. Ward, Zone etc.
Mandatory
MDMS
String
Yes
Hierarchy Type Code*
The code of the boundary hierarchies for which this particular boundary is defined
Mandatory
MDMS
String
Yes
Campaign Start Date
Date when the campaign starts in the respective boundary in dd/mm/yyyy format
Mandatory
MDMS
Date
Yes
Campaign End Date
Date when the campaign is supposed to end in the respective boundary in dd/mm/yyyy format
Mandatory
MDMS
Date
Yes
Total Households
Total households present in the boundary (as per the micro-plan)
Mandatory
MDMS
Numeric
Yes
Targeted Households
Total households targeted for the respective boundary (as per the micro-plan)
Mandatory
MDMS
Numeric
For bed net, the total and the targeted is likely to be the same
Yes
Total Individuals
Total individuals present in the boundary (as per the micro-plan)
Mandatory
MDMS
Numeric
Yes
Targeted Individuals
Total individuals targeted in the boundary (as per the micro-plan)
Mandatory
MDMS
Numeric
For bed net, the total and the targeted is likely to be the same
Yes
Bed nets estimated to be delivered
Total bed nets estimated to be delivered in the boundary (as per the micro-plan)
Mandatory
MDMS
Numeric
Yes
Product Type
Type of product being used. Example, drug, spray, vaccine, bed net, IEC Material
Yes
String
2
64
Product Name
Name of the product being used. Example, Ivermectic, Paracetamol, etc
Yes
String
2
64
Product Manufacturer
Name of the manufacturer. Example, Merck, Johnson & Johnson, etc
Yes
String
Product Variant
Capture the variant of the products. Products can vary based on shape, size, colour or other characteristics. Example, Para 200 mg- pack of 5 tables, Para 250 mg- pack of 10 tables
Yes
String
2
64
SKU
Stock keeping unit code for the product. Example, Para 200 mg and Para 250 mg
Yes
String
2
64
Base Unit Variant
Capture details if variant is the base unit used for record keeping of the product's inventory. Useful to filter variants applicable for tasks within a project. Example, Base unit for bed net is an individual bed net or a bale of 50 nets
Yes
String
Product Type
Product Name
Product Manufacturer
Product Variant
SKU
Base Unit Variant
Bed nets
Rectangular polyester mosquito net/bed net
Tana Netting FZ-LLC
Rectangular polyester mosquito net/bed net, 75-100 denier, treated with WHOPES recommended insecticide, colour: white/blue/green, dimensions 180x160x150cm (length x width x height) +/-5%
S0000981
Yes
Here are the articles in this section: