HCM Console Configuration
Overview
This document describes the configuration options available in the HCM (Health Campaign Management) Console. Its goal is to guide administrators, developers, and power-users to correctly set up and customise console behaviour for optimal performance, security, and user experience. These configurations include global settings, per-module options, UI customisations, environment-specific parameters, schema-based validations, feature flags, and integrations. To learn more about DIGIT HCM Service/App Configuration, click here.
Steps
Boundary Master Setup
The Boundary is the primary master data for a campaign. To upload it into the database, a hierarchy is needed. If the required hierarchy doesn’t exist, you can create one using the provided screens. Hierarchies can be created at any level.
Country -> Province -> District -> AdministrativePost -> Locality -> VillageNavigate to MDMS Configuration: Go to the MDMS data configuration page with the following parameters:
moduleName = HCM-ADMIN-CONSOLEmasterName = HierarchySchema
Set Up Console and Campaign Hierarchy:
Configure both the console and campaign using the hierarchy you want to apply.
Example: Admin
Maintain Consistency in Settings:
Ensure the hierarchy, lowest level, and split boundaries are the same for both console and campaign.
Use the same name as defined while creating the hierarchy.
Example:
Hierarchy: AdministrativePost
Lowest level: Locality
Navigate to the Boundary Data Management page and click on Create new boundary data.
Create the hierarchy and then download the template. Add data in the template.
Refer to the dummy template 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
The HierarchySchema in MDMS defines how boundaries are structured for campaign creation in the system.
Module Name:
HCM-ADMIN-CONSOLEMaster Name:
HierarchySchema
Key Fields
hierarchyType
Contains the different types of hierarchies supported.
Each hierarchy defines the levels of boundaries available (e.g., Province → District → Locality).
isActive
Determines which hierarchy type will be used to create a campaign.
Only the hierarchy marked as
isActive = truewill be applied.
lowestHierarchy
Represents the lowest boundary level visible to users on the boundary selection screen during campaign creation.
Example: If
lowestHierarchy = Locality, the campaign supervisor will select boundaries up to the locality level.
splitBoundariesOn
Defines the hierarchy level on which the target sheet tabs will be divided.
Example: If set to District, separate target sheets will be created per district.
consolidateUsersAt
Used during microplan integration.
Ensures user sheets are consolidated at a particular boundary level so that campaign user assignments (e.g., distributors, supervisors) are correctly populated.
In the HierarchySchema configuration, different type values are used to define the purpose of each hierarchy. These types determine how the hierarchy will be applied during different stages of the campaign.
Here, we have 4 types used in the campaign flow:
"type": "console": Used for the Campaign creation flow. Defines the boundary hierarchy structure that will be visible when creating a new campaign"type": "microplan": Used for the Microplan creation flow. Ensures that microplans are aligned to the configured boundary hierarchy."type": "campaign": Used for the Boundary Management creation flow. Specifies the hierarchy for managing campaign boundaries once a campaign is set up."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
Excel Upload Validation Schema
The system uses a single schema to validate Excel uploads, both on the UI and the backend. The schema ensures that uploaded data matches the required structure and rules. Each upload type has its own schema title.
If a user wants to change how validation works, the schema configuration must be updated.
Schema Properties
isRequiredMarks the columns that must be filled.
true→ the column is mandatory.false→ the column is optional.
orderNumberDefines the position of the column in the Excel sheet.
Ensures the columns are uploaded in the correct order.
titleRepresents the schema title.
Each title is linked to the type of upload (e.g., user upload, campaign upload, etc.).
enumLists the allowed values for a field.
Ensures that only predefined options can be entered (e.g.,
"Male","Female","Other"for gender).
numberPropertiesApplies to numeric fields.
Defines constraints such as:
uniqueness (whether duplicate values are allowed),
required status,
minimum/maximum limits.
stringPropertiesApplies to text fields.
Defines rules such as:
required status,
uniqueness,
length restrictions (minimum/maximum characters),
content constraints (e.g., regex patterns).
Excel Validation Configurations
The schemas stored under the MDMS configuration define how validations are applied for different Excel uploads. These validations apply at both the UI and backend levels.
Module Name:
HCM-ADMIN-CONSOLEMaster Name:
schemas
If users want to adjust or extend the validations, they can do so by updating the schema.
Types of Validations
1. User Validations
Roles → Add or remove roles to be validated.
Employment Type → Update the
enumlist to add or remove types.Headers → All headers are mandatory by default, but you can toggle this by setting
isRequired = true/false.
2. Facility Validations
Facility Type → Add or delete facility categories.
Facility Status → Add or delete status options.
Facility Usage → Add or delete usage options.
Capacity → Adjust
minimumandmaximumvalues.Facility Name → Update constraints for
minLengthandmaxLength.Headers → All headers are mandatory by default; adjust using
isRequired.
3. Target Validations
Target → Adjust
minimumandmaximumvalidations.Boundary Code → Mandatory field.
Target Header → Mandatory field.
Campaign Type → Based on the selected campaign type, boundary targets are updated.
Custom Columns → New target columns can be introduced if required.
While introducing a new campaign/project type, this admin schema needs to be added for that type.
3. Attributes Configuration
The schema includes a list of attribute configurations, where each attribute is:
Identified by a unique key,
Defined with a code, and
Linked to an internationalisation key (i18nKey) for multi-language support.
Example Attributes
The following attributes are available for use in campaigns to capture beneficiary information:
Age
Height
Weight
Gender
These attributes ensure that consistent, standardised data points are collected across campaigns.
The attribute dropdown in the system is dynamically populated from the attributeConfig schema. This schema defines the set of attributes available for selection during campaign setup or data entry.
Module Name:
HCM-ADMIN-CONSOLEMaster Name:
attributeConfig
4. Base Timeout
This schema defines the rules for how frequently the system should call the search API after a file upload. The purpose of these calls is to check the validation status of the uploaded file.
Module Name:
HCM-ADMIN-CONSOLEMaster Name:
baseTimeOut
How It Works
Base Time
Defines the minimum interval after which the search API is triggered.
Dynamic Interval Calculation
The actual interval = baseTime × number of fields in the uploaded sheet.
This interval is constrained by:
Minimum base time (lower limit), and
maxTime (upper limit).
Search API Calls
The search API is called repeatedly at the calculated interval.
Calls stop only when a successful or failed response is received.
TimelineRefetch
Configured to call the getProcessAPI of the timeline periodically.
Ensures the process status is kept up to date after a certain interval.
6. Delivery Type Configuration
The delivery configuration schema is used to define how deliveries are displayed in the system. It distinguishes between:
Direct Deliveries → Items or services provided directly to the beneficiary.
Indirect Deliveries → Items or services provided through an intermediary (e.g., via a facility, distributor, or supervisor).
Module Name:
HCM-ADMIN-CONSOLEMaster Name:
deliveryTypeConfig
7. Mail Configuration
The mailConfig schema is used to define the default email ID for contacting the L1 support team or the implementation team. This comes into play when a user requests a hierarchy that is not currently available in the system.
Module Name:
HCM-ADMIN-CONSOLEMaster Name:
mailConfig
8. Operator Configuration
The operatorConfig schema defines all the operator options that can be applied to attributes. These operators are used in the system for filtering, validation, and logical conditions during campaign configuration and execution.
Module Name:
HCM-ADMIN-CONSOLEMaster Name:
operatorConfig
9. Product Type
The productType schema defines the list of resource types that can be selected in the system. If a required resource type is not already available, it can be added through this schema. Once added, the new resource type will automatically appear in the resources dropdown.
Module Name:
HCM-ADMIN-CONSOLEMaster Name:
productType
10. ReadMe Configuration
The ReadMeConfig schema defines the information messages that are displayed both in the UI and in the ReadMe sheet of the downloaded Excel templates. These messages act as instructions for users, guiding them on how to correctly fill in the upload templates.
Module Name:
HCM-ADMIN-CONSOLEMaster Name:
ReadMeConfig
Below is an example of how data is entered into the read-me schema for the headers and their description:
Schema Fields
type: Defines the upload type (e.g., User, Facility, Target).
header: The text identifier for the header (localised using the localisation module).
isHeaderBold: Boolean → whether the header should be displayed in bold.
inSheet: Boolean → whether the header should appear in the downloaded Excel sheet.
inUiInfo: Boolean → whether the header should appear in the UI information panel.
text: The text identifier for the description (localised).
isStepRequired: Boolean → whether the description is a mandatory step for users.
Localisation
All header and text values are stored as codes, which are then mapped through the localisation module.
This ensures multi-language support for instructions across the platform.
hcm-admin-schemas11. Login Configuration
To display the Privacy Policy component on the login page, you need to add the required configurations in MDMS.
Module Name:
LoginConfigMaster Name:
commonUiConfig
In version v0.4, the login page was revamped, and the configuration was updated accordingly.
Steps
Navigate to the MDMS configuration for the login page.
Locate the module:
LoginConfig.In the
commonUiConfigmaster, add or update the fields as required.You can customise the fields (add or delete) depending on your implementation needs.
For detailed configuration examples and usage, 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
typeisnull, it indicates that the description is just plain text.
point:When
typeis set topoint, it likely means that the description should be displayed as a bullet point or list item.
step:When
typeis 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 create 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 restrict the App config to unselect some module if optional
master details HCM-ADMIN-CONSOLE.AllowedModules
3. AppLink
This configuration is used to provide the Downloadable APK link, after the campaign is created.
So APK needs to be manually generated here and update the link in this master
master details HCM-ADMIN-CONSOLE.AppLink
4. AppModuleSchema
This configuration is used to define the Modules & its features in App config flow
master details HCM-ADMIN-CONSOLE.AppModuleSchema
5. AppScreenLocalisationConfig
This configuration is used to define the property to localistion to be enabled in App config flow
master details HCM-ADMIN-CONSOLE.AppScreenLocalisationConfig
6. FormConfigTemplate
This configuration is used as the base template for the form config screens 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?