HCM Console Configuration
Overview
The document is a guide to the various configuration options available in the HCM Console. Proper configuration is crucial for optimising performance, ensuring security, and customising the user experience to meet specific needs. This document is designed to help system administrators, developers, and end-users understand and implement these configurations effectively. To learn more about DIGIT HCM Service/App Configuration, click here.
Scope
This guide covers all aspects of application configuration, including global settings, module-specific options, and environment-specific adjustments. It addresses configuration methods such as through files, environment variables, and command-line arguments. Additionally, it includes advanced configuration topics like custom scripting, API integrations, and feature flag management.
Audience
The primary audience for this document includes:
System Administrators: Responsible for setting up and maintaining the application in various environments.
Developers: Need to understand configuration options for development, testing, and deployment.
End-Users: They may require guidance on configuring user-specific settings via the user interface.
Structure
The document is organised into the following sections:
Configuration Types: Detailed descriptions of global, module-specific, and environment-specific settings.
Configuration Methods: Instructions on how to apply configurations using different methods.
Common Configuration Options: Examples of frequently used settings, including database connections, authentication, logging, and UI adjustments.
Advanced Configurations: Information on extending the application's functionality through custom scripts, plugins, and integrations.
Best Practices: Recommendations for managing configurations securely and efficiently.
Troubleshooting: Solutions to common configuration problems and tips for debugging issues.
Appendices: Additional resources, including a glossary and references for further reading.
By following the instructions in this document, users can ensure that the application is configured correctly to meet their operational needs, enhancing both performance and user satisfaction.
This overview section sets the stage for the rest of the document by clearly outlining its purpose, scope, intended audience, and overall structure.
Previous version Documents
Boundary Master Setup
The Boundary serves as the primary master data for a campaign and can be configured using the screen provided below. To upload a boundary into the database, a hierarchy is required. If the necessary hierarchy is not available in the existing list, it can be created using the designated screen. Hierarchies of any level can be established.
Country -> Province -> District -> AdministrativePost -> Locality -> Village
First, navigate to the MDMS data configuration page with moduleName = HCM-ADMIN-CONSOLE and masterName = HierarchySchema and configure the console and campaign as the hierarchy you want to have (Example - Admin)
Keep hierarchy, lowest level, and split boundaries on column same for console and campaign, and name should be the same as defined while creating hierarchy. (Example: Here we have AdministrativePost and Locality)

Now navigate to the boundary management page and continue with boundary creation.



After creating the hierarchy, you can download the template and add data to it.

In this screen, the user needs to download the template containing boundary levels in the headers according to the hierarchy. The user needs to fill in that template in a specific format. A dummy template is attached for reference.
All the boundaries are localised to the localisation module below:
hcm-boundary-${BOUNDARY_HIERARCHY_TYPE} // hierarchy type should be according to the selected hierarchy and the module has everything in lowercase.
MDMS Data Setup
1. Hierarchy Configuration
This schema contains different hierarchy types and their lowest hierarchy.
Based on isActive, choose which type of hierarchy the campaign will be created in. This configuration defines the boundary hierarchy on which a campaign can be created. All the boundary levels are coming according to the hierarchy configured.
The lowestHierarchy
will represent the lowest level hierarchy to be displayed in the boundary selection screen while creating a campaign.
The SplitBoundariesOn
defines the hierarchy level for dividing the target sheet tabs.
The consolidateUsersAt
the function is utilised during microplan integration, ensuring user sheets are populated -

The Console is being referred to for campaign creation. The campaign is being referred for boundary management.
Here, we have 4 types which are being used in the campaign flow:
"type": "console"
: Used for the Campaign creation flow."type": "microplan"
: Used for the Microplan creation flow."type": "campaign"
: Used for the Boundary Management creation flow."type": "default"
: Serves as the default hierarchy for Boundary Management creation flow and holds default settings.
We support the development and handling of various use cases. However, we recommend using the same hierarchy configuration across all types to ensure a seamless flow. This allows for creating a microplan within the same hierarchy, building campaigns on it, and managing the boundary hierarchy consistently.
2. Template Validations ( Schemas)
Based on this schema, validations happen in Excel from both the UI and the backend for the different uploads; there is one schema with the title according to the uploaded type. If a user wants to change anything in the Excel validation, then the data of the schema needs to be updated.
Schema properties:
IsRequired
: True for all those columns that are mandatory to be filled
orderNumber
: Position where that column will be present
title
: Set according to the type of upload
enum
: Defines a set of allowed values for a specific property, ensuring that only predefined, valid options can be assigned to that property.
numberProperties
: Numeric fields with specific characteristics such as uniqueness, required status, and value constraints like minimum and maximum limits.
string properties
: Text fields with specific characteristics such as required status, uniqueness, and constraints on length and content.
Users can change the following validations from Excel using this schema, such as:
User Validations -
Roles - Roles to be validated can be added or deleted in the schema.
Employment Type - This can be changed from the enum.
All the headers are mandatory; they can be adjusted according to the requirement by changing isRequired to true/false.
Facility Validations -
Facility Type - More types can be added or deleted.
Facility Status - More requirements can be added or deleted.
Facility Usage - More requirements can be added or deleted.
Capacity - Minimum and maximum can be changed.
Facility Name - Maximum length and minimum length can be changed.
All the headers are mandatory; they can be adjusted according to the requirement, just by changing isRequired to true/false.
Target Validation -
Target - Minimum and maximum validations can be changed.
Boundary code and target header are mandatory.
It also has a field called campaign type, so based on the campaign type boundary target is updated, and any new target column can be introduced.
While introducing a new campaign/project type, this admin schema needs to be added for that type.
3. Attributes Configuration
It includes a list of attribute configurations, each identified by a unique key and specified by a code and an internationalisation key (i18nKey). The attributes listed are 'Age', 'Height', 'Weight', and 'Gender', which can be used in campaigns to capture relevant information.

The attribute dropdown is populated from this schema. If the user wants to add or delete attribute options, this schema is helpful.
4. Base Timeout
This schema configures the base time interval after which the search API is called following a file upload. The search API checks the validation status of the uploaded file. The frequency of the API calls is determined by the data present, with the time interval calculated as the base time multiplied by the number of fields in the sheet, constrained by both the minimum base time and the maxTime stated in the schema. The search API will continue to be called repeatedly until a successful or failed response is received. TimelineRefetch is also added to call the getProcessAPI of the timeline after a certain interval of time.
6. Delivery Type Configuration
This is used in the delivery configuration schema to show the direct and indirect deliveries.
7. Mail Configuration
It has the default mail ID to contact the L1 or implementation team if the hierarchy a user wants is not present. The mail ID can be configured from this schema -
8. Operator Configuration
This schema contains all the operator options which are required for the attributes.

9. Product Type
This schema displays the options to add the resource type if the resource a user wants is not present in the options. The resource added here will be present in the resources dropdown, so prevent adding any junk data.

10. ReadMe Configuration
This schema is used to display the info message in the UI and the read-me sheet in the downloaded template. It configures according to the upload type, which shows the instructions to a user on how to fill the template. These codes are localised according to the message.

Below is an example of how data is entered into the read-me schema for the headers and their description:
type: defined the type of upload.
header: The text identifier for the header.
isHeaderBold: A boolean indicating whether the header text should be displayed in bold.
inSheet: A boolean indicating whether this header should be included in the sheet.
inUiInfo: A boolean indicating whether this header should be displayed in the UI.
text: The text identifier for the description.
isStepRequired: A boolean indicating whether this description step is required.
All the headers and descriptions are written in code that is localised using the localisation module named:
hcm-admin-schemas
11. Login Configuration
To show the privacy policy component on the login page, a user needs to include the configurations in the MDMS: In the current (v0.4), we made a revamp of the login and updated the config accordingly
Master Name: commonUiConfig
ModuleName: LoginConfig
In this user can customise (add/delete) the fields according to the requirement.
For more details, you can refer here.
12. Policy Configuration
This configuration displays the data in the privacy pop-up. An example of the configuration is shown below:
In the schema:
Type can be the following:
null:
When
type
isnull
, it indicates that the description is just plain text.
point:
When
type
is set topoint
, it likely means that the description should be displayed as a bullet point or list item.
step:
When
type
is set tostep
, it suggests that the description is part of a sequence of steps.
subdescriptions: to show the sub-descriptions at the point.
13. Date with Boundary
This configuration is used when you want to update the dates with or without the selected boundaries.
If the flag is false, then by default it updates the dates at the country level. If you want to update the dates at the lower boundary levels, then make the flag true.
14. Project Type Configuration
This configuration is now used in place of the delivery configuration.
This is used to store all the pre-required conditions for the delivery conditions screens.
Master Name: HCM-PROJECT-TYPES
ModuleName: projectTypes
This is the sample data for the project type - MR-DN
Explanation for the MDMS Data -
Project Types: Three main project types (
LLIN-mz
,MR-DN
, andIRS-mz
) with unique configurations.Cycles and Deliveries:
Each project type contains cycles, and each cycle contains multiple deliveries.
Deliveries include details such as
deliveryStrategy
,doseCriteria
, andProductVariants
.
Resources: A list of resources specific to each project type.
Eligibility Criteria: Contains a list of conditions for each project type.
Other Configurations:
attrAddDisable
,deliveryAddDisable
, and similar attributes determine UI behaviour.
Requirements:
Mandatory to set the product variant ID according to the environment.
"ProductVariants": [
{
"productVariantId": "PVAR-2024-05-09-000331", // should be set according to the environment
"quantity": 1,
"name": "SP 500mg"
},
]
15. Roles for Checklist
This master data is used to show the dropdown of roles in the checklist screens -
16. Checklist Templates
This master data is used to default template of the checklist for the selected campaign + role + checklist type -
17. App Field Types
This is used to describe the type of questions available in the dropdown while configuring the checklist.
18. Microplan Integration
This master is utilised for the microplan data fetching. Here, 'type' refers to the data template that needs to be filled. 'To' and 'from' pertain to the microplan data, and while populating campaign data, various filter conditions, such as 'includes', or 'equals', can be applied.
19. IdGen Configuration
To enable the generation of unique identifiers via the idGen service, the following data must be added to the MDMS under moduleName=common-masters
and masterName=IdFormat
.
Ensure both configurations are added to MDMS before proceeding with ID generation.
20. Target Configuration
This configuration is used to define the mapping of target-related data from the target sheet to different beneficiary types. Each beneficiary type can be associated with one or more columns from the target sheet, which hold the respective target values.
Key Details:
campaignType: Specifies the campaign type this configuration applies to (e.g., "LLIN-mz").
beneficiaries: A list of beneficiary types, each having:
columns: The columns in the target sheet that map to this beneficiary type.
beneficiaryType: The type of beneficiary (e.g., "INDIVIDUAL", "HOUSEHOLD", "PRODUCT").
New Schemas Added
1. HelpTutorial
This configuration is used to define help tutorial content for the users during the flow
master details commonUiConfig.HelpTutorial
2. AllowedModules
This configuration is used to define help tutorial content for the users during the flow
master details HCM-ADMIN-CONSOLE.AllowedModules
3. AppLink
This configuration is used to define help tutorial content for the users during the flow
master details HCM-ADMIN-CONSOLE.AppLink
4. AppModuleSchema
This configuration is used to define help tutorial content for the users during the flow
master details HCM-ADMIN-CONSOLE.AppModuleSchema
5. AppScreenLocalisationConfig
This configuration is used to define help tutorial content for the users during the flow
master details HCM-ADMIN-CONSOLE.AppScreenLocalisationConfig
6. FormConfigTemplate
This configuration is used to define help tutorial content for the users during the flow
master details HCM-ADMIN-CONSOLE.FormConfigTemplate
We also have one more master FormConfig, AppConfigCache, which needs only schema, data will be auto added during campaign configuration.
7. CampaignNamingConvention
To add a similar configuration for HCM-ADMIN-CONSOLE.CampaignNamingConvention
, follow these steps:
8. FieldPropertiesPanelConfig
9. FieldTypeMappingConfig
Master Details
HCM-ADMIN-CONSOLE.FieldTypeMappingConfig
10. DETAILS_RENDERER_CONFIG
Master details
HCM-ADMIN-CONSOLE.DETAILS_RENDERER_CONFIG
Removed Masters
1. adminSchemas
Helm Configurations
Refer here to learn more about the helm configurations
Last updated
Was this helpful?