Template documentation

Template Screens & App Configuration – Technical Design Documentation

1. Introduction

The Template Screen is a metadata-driven, dynamic UI architecture for managing project- or campaign-based workflows. Its purpose is to decouple UI structure from UI behavior, placing all layout, ordering, visibility, and localisation logic into a centrally managed MDMS (Master Data Management System).

Key benefits include:

  • consistent, reusable component definitions

  • complete multi-language support

  • version-controlled, maintainable configurations

  • easier campaign rollouts without code redeployment

At its core, the Template feature uses:

  • GenericTemplateScreen as a dynamic renderer

  • RegistrationComponentRegistry as a component resolver

  • TemplateRenderer for advanced nested layouts / custom layouts

  • MDMS configurations for a single source of truth for app configurations

2. Architecture Overview

✅ GenericTemplateScreen

  • Loads a page’s field configuration

  • Renders each field using the Registry

  • Supports a fixed button bar for Primary/Secondary actions

  • Delegates to a TemplateRenderer when a corresponding component is registered in the RegistrationComponentRegistry under the specified templateName..

✅ RegistrationComponentRegistry

  • Maps component jsonPath to a registered React component

✅ TemplateRenderer

  • Handles nested/grouped or repeated layouts with custom render logic

✅ MDMS

  • Acts as the central, version-controlled data store for campaign and project configurations.

3. App Configuration Feature

The App Configuration feature supports implementation teams and administrators to:

  • design dynamic forms

  • visually reorder or edit fields

  • add new pages and sections

  • manage labels and multi-language strings

  • preview final mobile app configurations before deployment

3.1 UI Flow

The configuration UI includes:

✅ Drawer (Side Panel)

  • Provides field/component editing with:

    • label

    • tooltip

    • validations

    • hide/show

    • localisation keys

✅ Supported Actions

  • Reorder buttons in template screens via drag-and-drop

  • Set components as hidden or shown

  • Manage localisation for each component label and its properties

  • Save, submit, or update configurations

3.2 Typical User Flow

  1. Administrator clicks "Configure Mobile App"

  2. Chooses one or more enabled modules

  3. App configuration screen loads based on MDMS

  4. User edits the form structure or template design using the drawer panel properties

  5. User submits the final configuration

  6. The new MDMS config is version-controlled and available to render immediately in the mobile application

4. Data & State Layers

✅ Parent Layer

  • Fetches and restructures the MDMS configuration on load

  • Normalizes data for easy preview

✅ Localisation Layer

  • Handles which fields are localisable

  • Provides live translation preview

✅ App Config Wrapper

  • Renders the live preview of the configured screen

  • Handles user edits through the side drawer

5. Rendering Workflow in GenericTemplateScreen

✅ Filters hidden fields ✅ Splits Primary/Secondary buttons ✅ Sorts button components by order ✅ Delegates to TemplateRenderer if component with templateName exists ✅ Otherwise loops through all fields and renders via the Registry ✅ Buttons appear in a fixed-position footer

6. Extensibility Guide

✅ To add a new component:

  1. Implement a React component with

({ field, t }) => { ... }

  1. Register with the Registry

registerComponent("customComponent", CustomComponent);

  1. Add to FormConfigTemplate with jsonPath and format

  2. If its label should be changeable in App Config, add its format to:

  • FieldPropertiesPanelConfig → visibilityEnabledFor

  1. Register its type in FieldTypeMappingConfig

  2. Validate on preview

✅ To add a nested TemplateRenderer:

  1. Write

({ components, t }) => { ... }

  1. Register with getTemplateRenderer

export const getTemplateRenderer = (templateName) => {

switch (templateName) { case "AnotherTemplate": return anotherRenderer; } };

  1. In MDMS Form Config, make sure templateName matches the page name

  2. Validate end-to-end

7. MDMS Configurations

7.1 FormConfig Example

{ "name": "REGISTRATIONFLOW", "order": 1, "pages": [ { "page": "SearchBeneficiary", "type": "template", "label": "APPONE_REGISTRATION_BENEFICIARY_SEARCH_SCREEN_HEADING", "order": 1, "navigateTo": { "name": "overview", "type": "template" }, "properties": [ { "type": "template", "format": "filter", "jsonPath": "filter", "order": 1 }, { "type": "template", "format": "searchByProximity", "jsonPath": "searchByProximity", "order": 2 }, { "type": "template", "format": "PrimaryButton", "jsonPath": "PrimaryButton", "order": 3 }, { "type": "template", "format": "searchBar", "jsonPath": "searchBar", "order": 4 }, { "type": "template", "format": "SecondaryButton", "jsonPath": "SecondaryButton", "order": 5 } ] } ] }

7.2 FieldTypeMappingConfig

{ "type": "searchByProximity", "metadata": { "type": "template", "format": "searchByProximity" }, "fieldType": "searchByProximity" }

These components are defined with the template type, which means they cannot be added as standalone fields or components in other screens.

7.3 FieldPropertiesPanelConfig

{ "tab": "content", "label": "label", "bindTo": "label", "fieldType": "text", "visibilityEnabledFor": [ "filter", "searchByProximity", "DetailsCard", "Table", "PrimaryButton", "SecondaryButton" ] }

Adding your component’s type to the visibilityEnabledFor property ensures that the label localisation field is available in the drawer panel, allowing users to dynamically translate and edit component labels in supported languages.

7.4 DETAILS_RENDERER_CONFIG

{ "entity": "Task", "displayFields": [ { "fieldKey": "doseIndex", "jsonPath": "Task.additionalFields" }, { "fieldKey": "status", "jsonPath": "Task.status" }, { "fieldKey": "createdTime", "jsonPath": "Task.auditDetails.createdTime" } ] }

This structure powers the nested options in the AppConfig drawer for DetailsCard and Table so users can dynamically select which fields to render, and override their labels.

8. Custom Components: DetailsCard/Table with Enums

For DetailsCard or Table, the FormConfig uses an enums array:

{ "type": "template", "format": "Table", "jsonPath": "Table", "order": 2, "enums": [ { "code": "Task.deliveryNo", "name": "deliveryNo", "jsonPath": "Task.additionalFields" }, { "code": "Task.status", "name": "status", "jsonPath": "Task.status" } ] }

These enums are dynamically sourced from the HCM-ADMIN-CONSOLE.DETAILS_RENDERER_CONFIG schema, enabling campaign users to flexibly select fields, assign localised labels, and even modify Table component column names

9. Summary

Helpers

Description

GenericTemplateScreen

Dynamic runtime renderer for a page

RegistrationComponentRegistry

Maps jsonPath or format to React components

TemplateRenderer

Handles nested or grouped page layouts

FieldTypeMappingConfig

Maps type and metadata so the admin console can recognize the field/component

FieldPropertiesPanelConfig

Controls what can be changed in the drawer editor

DETAILS_RENDERER_CONFIG

Provides reusable field keys for DetailsCard and Table

MDMS FormConfigTemplate

Describes page flow, fields/components, ordering, and navigation

10. Best Practices

✅ Always assign unique jsonPath values ✅ Keep field and entity codes consistent (entity.fieldKey) ✅ Validate localisation keys across all supported languages ✅ Prefer stateless, pure React components ✅ Document new TemplateRenderers thoroughly ✅ Always test edge cases in the preview environment before final submission

11. Conclusion

This template feature provides a metadata-first, no-code-friendly strategy for dynamic app configuration. By leveraging:

  • GenericTemplateScreen

  • RegistrationComponentRegistry

  • TemplateRenderer

  • FieldTypeMappingConfig

  • DETAILS_RENDERER_CONFIG

PreviousTechnical Documentation (Improved)NextCentral Instance

Was this helpful?