user-tieAdmin User

Overview

The Admin Panel provides comprehensive field configuration and document mapping capabilities for a beneficiary app. The system enables Admins to define custom form fields, configure document types, and establish mappings between form fields and document VCs (verification credentials) .

Use Cases

1. Manage Profile Fields

Create, edit, and delete custom fields for user profile

Main Flow:

  1. Admin navigates to Add Fields page

  2. System displays current list of fields in table format

  1. Admin clicks "Add Field" button System opens field creation modal Field creation modal opened with empty form

  1. Admin fills required field information:

  • Label (display name)

  • Name (internal identifier)

  • Type (text, numeric, date, boolean, dropdown)

  • Ordering (display sequence)

  • Required flag

  • Editable flag

  • Options (for dropdown type)

Label (Multi-Language Support) Label is the display name of the field shown to users.

This field supports multi-language configuration. Based on the language configuration, separate language tabs are displayed under the Label section.

The user must enter the label value for each configured language.

Modal with all field information filled out

  1. Admin clicks Add field button

  2. System validates field data

  3. System calls API to persist field

  4. System refreshes field list

  5. Updated fields table showing newly added field

  6. System displays success confirmation

Alternative Flows:

  • AF-001a: Edit existing field

  • AF-001b: Delete field

Business Rules:

  • Field names must be unique

  • Ordering must be numeric and positive

  • Dropdown fields must have at least one option

  • Fields in use cannot be deleted

2. Configure Document Types

Beneficiary Admin Goal: Define document types and their VC field schemas, and field-level validation and matching rules applied during beneficiary document uploads

Preconditions:

  • Admin has access to admin panel

  • Document Types are configured and available in the system

  • Issuers are configured and available

  • VC schemas are supported by the issuance platform

Main Flow:

2.1 Access Document Configuration Page

  1. Admin navigates to Admin Panel → Document Configuration

  2. System fetches:

    • Existing document configurations

    • Available Document Types

    • Available Issuers

  3. Existing configurations are displayed as editable blocks

2.2 Add or Review Document Configuration

Each document configuration contains the following fields:

  • Document Name (Mandatory) Display name of the document.

  • Document Label (Mandatory) User-friendly label shown in the UI.

  • Document Type (Mandatory) High-level category of the document.

  • Document Sub Type (Mandatory, Unique) Unique identifier used internally for processing and mapping.

  • Document Issuer (Mandatory) Issuer of the Verifiable Credential. Selected from the dynamically loaded issuer list

  • Issue VC? (Mandatory) Indicates whether a Verifiable Credential should be issued for this document. Supported values:

    • Yes

    • No

  • Space ID (Mandatory if Issue VC = Yes) Space in which the VC will be created and stored.

  • Document Has OR Code? (Mandatory if Issue VC = No) Indicates whether the document contains a QR code.

  • Doc QR Contains (Mandatory if Has QR Code = Yes) Defines the data format embedded in the QR code.

  • Enable Pre-Validation (Mandatory) Enable keyword-based pre-validation checks before OCR processing.

  • Pre-Validation Required Keywords (Optional) Keywords that must be present in the OCR extracted text for the document to be considered valid.

  • Pre-Validation Exclusion Keywords (Optional) Keywords that must NOT be present in the OCR text.

  • Document Fields (JSON) (Mandatory) JSON schema defining VC fields, validation rules, and matching logic.

  • Enable Post-Validation (Mandatory) Enable or disable field-based post-validation checks after OCR processing. Only available when VC Fields is valid.

  • Post-Validation Required Keywords (Optional) Fields to check after data mapping. Validation passes when the minimum required number of these fields is present. Only keys from document Fields JSON are allowed.

  • Post-Validation Field Mapping Number (Optional) Minimum number of required fields that must be present. If left empty, all selected fields are required.

  • Field Mapping Prompt (Optional) Prompt template which control how AI extracts and validates data from OCR text.

2.3 Document Label configaration

The Document Label represents the display name of the document type shown across the application, such as in document lists, upload screens, and review pages.

This label helps users easily identify the document type. The document label supports multi-language configuration.

Based on the system’s language configuration, multiple language tabs are displayed under the Label section.

Each tab corresponds to one supported language.

For example:

  • English

  • हिंदी

Configuring Document Label

To configure the document label:

  1. Select a language tab.

  2. Enter the document label in the selected language.

  3. Switch to the next language tab and provide the translated label.

  4. Repeat this process until labels are entered for all configured languages.

Mandatory Requirement

  • Label values are mandatory for all configured languages.

  • The document configuration cannot be saved if any language label is missing.

Example

Language
Document Label

English

Caste Certificate

हिंदी

जाति प्रमाणपत्र

Display Behavior

  • The label is displayed to beneficiary users based on their selected application language.

  • The default system language label is used as the primary reference.

2.4 Conditional Configuration Logic

Conditional logic applies only at the document configuration level.

If Issue VC = Yes

  • Space ID (Mandatory)

    • Space in which the VC will be created

    • Used by the Beneficiary App during VC issuance

If Issue VC = No

  • Document Has OR Code? (Mandatory)

    • Indicates whether the document contains a QR code

    • Options:

      • Yes

      • No

If Document Has OR Code? = Yes

  • Doc QR Contains (Mandatory)

    • Defines the type of data encoded in the QR code

    • Supported formats:

      • Doc URL

      • VC URL

      • Plain Text

      • Text and URL

      • JSON

      • JSON URL

      • XML

      • XML URL

2.5 Pre-Validation Configuration

Pre-validation checks whether the uploaded document is the correct and valid document before the system starts extracting fields from it.

This check happens after OCR reads the document text and before field mapping starts. It helps the system quickly reject wrong, fake, or irrelevant documents.

Pre-validation occurs in the following sequence:

  1. Beneficiary uploads a document

  2. OCR engine extracts raw text from the document

  3. Prevalidation rules are applied

  4. Only validated documents proceed to field mapping

Pre-Validation Configuration Fields

1. Enable Pre-Validation (Mandatory) Controls whether pre-validation rules should be applied. Options:

  • Yes → Pre-validation rules are enforced

  • No → Document directly proceeds to mapping

2. Pre-Validation Required Keywords Defines keywords that must be present in the OCR extracted text. If any required keyword is missing, the document is considered invalid.

Examples: For income certificate Required Keywords:

  • Income certificate

  • Income

If OCR text does not contain both keywords → validation fails.

3. Pre-Validation Exclusion Keywords Defines keywords that must NOT appear in the OCR extracted text. If any exclusion keyword is detected, the document is rejected.

Examples: For income certificate Exclusion Keywords:

  • Caste certificate

  • Bonafide certificate

If OCR text does contain any of above keywords → validation fails.

Example: Marksheet Certificate

Description: Above image represents a valid marksheet certificate uploaded by the beneficiary. The OCR engine extracts text from this document, and pre-validation rules are applied based on configured keywords.

Pre-Validation Rules Applied

Required Keywords (Keywords that MUST be present for the document to be valid)

  • Marks Statement

  • Results of Annual Secondary Examination

Exclusion Keywords (Keywords that MUST NOT be present for the document to be valid)

  • Bonafide Certificate

  • Income Certificate

Validation Result:

  • If both required keywords are present → ✅ Document uploaded successfully!

  • If any exclusion keyword is detected → ❌ Invalid document type. Required: Marksheet

2.6 VC Schema Configuration (Document Fields JSON)

The VC Fields configuration defines the structure, validation rules, and matching logic for the Verifiable Credential.

  • Must be a valid JSON object

  • Defines which fields are extracted, validated, and stored in the VC

  • Applied at runtime during document upload in the Beneficiary App

2.6.1 VC Field Properties Each field inside vcFields supports the following properties:

Property
Type
Description

type

string

Data type of the field (e.g., string, number)

required

boolean

Whether the field must be present in the document

maxLength

number

Maximum allowed length of the field value

pattern

string

Regular expression for validating the field format

description

string

Human-readable description of the field

matching

object

Enables profile-based field comparison

validationMessages

object

Language-specific validation error messages

label

object

Stores the display label of the field or document in multiple languages.

label.en

string

Label value in English. Used when the application language is set to English.

label.hi

string

Label value in Hindi. Used when the application language is set to Hindi.

Example

chevron-rightDocument Fields Configuration of Marksheethashtag

2.6.2 required Property – The required property enforces mandatory presence of a VC field during document upload.

Validation flow:

  1. Document is scanned or imported

  2. OCR / QR extraction is performed

  3. All fields marked required: true are validated

  4. If any required field is missing:

    • Upload is rejected

    • No VC is created

2.6.3 Format & Length Validation

pattern

  • Validates field value using a regular expression

  • Commonly used to restrict special characters or enforce format

maxLength

  • Ensures the extracted value does not exceed the defined limit

Example

If student_name exceeds 255 characters or contains invalid symbols:

  • Upload fails

  • Language-specific validation message is shown

2.6.4 validationMessagesMulti-Language Support

The validationMessages object provides localized error messages for each validation rule.

Supported Languages

  • English (en)

  • Hindi (hi)

Benefits

  • User-friendly validation feedback

  • Consistent backend-driven error messaging

  • Easy extension for additional languages

2.6.5 matching Object – Profile Validation

The matching object ensures document authenticity by comparing extracted values with beneficiary profile data.

  • compareWith: The beneficiary profile field against which the document field will be compared

  • matchPercentage: Minimum similarity threshold required for the document to be accepted

When document is being uploaded by the beneficiary user:

  1. Extracts field value from document

  2. Fetches corresponding profile value (compareWith)

  3. Normalizes both values

  4. Calculates similarity using string-matching algorithms

  5. Compares similarity against threshold (matchPercentage)

Result:

  • Similarity ≥ matchPercentage → ✅ Pass

  • Similarity < matchPercentage → 'failedFields' does not match the user profile. Please re-upload the document.

How to configure matchPercentage

The threshold value directly controls how strict or flexible the name matching should be.

1. Recommended threshold values

Threshold
Behavior

90–100%

Very strict matching

80–89%

Balanced and recommended

70–79%

Lenient matching

Below 70%

Not recommended

2. High Threshold (90–100%)

Use when:

  • Exact name matching is required

  • Document quality is high

  • Risk of fraud must be minimized

Example:

Profile Name: Tipu Sultan

Document Value
Match %
Result

TIPU SULTAN

100%

✅ Pass

TIPPU SULTAN

94.74%

✅ Pass

TIPU SULTAN.

94.74%

✅ Pass

TIPU-SULTAN

84.21%

❌ Fail

⚠️ Minor OCR errors may cause rejection.

3. Medium Threshold (Recommended – 80%)

Allows:

  • Minor OCR mistakes

  • Extra titles or prefixes

  • Formatting differences

Example:

Profile Name: Tipu Sultan

Document Value
Match %
Result

TIPPU SULTAN

94.74%

✅ Pass

TIPU SULTHAN

84.21%

✅ Pass

MR TIPU SULTAN

90%

✅ Pass

SHRI TIPU SULTAN

81.82%

✅ Pass

TIPU SULTAN SAHAB

78.26%

❌ Fail

✅ Best balance between accuracy and flexibility.

4. Low Threshold (70–79%)

Use only when:

  • OCR quality is poor

  • Document formats vary heavily

Risk:

  • Higher chance of accepting incorrect names

Example:

Document Value
Match %
Result

Sultan Tipu

88.89%

✅ Pass

Mohammed Tipu Sultan

69.23%

❌ Fail

RAMU SULTAN

66.67%

❌ Fail

2.7 Post-Validation Configuration

Post-Validation is validation stage that runs after field mapping is completed.

It validates whether the extracted and mapped fields are sufficient, reliable, and complete for acceptance of document.

Post-validation settings are only available after VC Fields (Document Fields JSON) are configured. If no VC fields are added post-validation configuration fields are disabled

Post-validation occurs after:

  1. OCR extraction

  2. Pre-validation (if enabled)

  3. Field mapping using Document Fields JSON

  4. Post-validation rules are applied

Post-validation Configuration Fields

1. Enable Post-Validation (Mandatory) Controls whether post-validation rules should be applied. Options:

  • Yes → Post-validation is enforced

  • No → Mapping result is accepted directly

2. Post-Validation Required Keywords Post-validation required keywords can be added only from the VC Fields configured in the Document Fields (VC Fields JSON).

  • Only VC field keys are allowed

  • Other keywords are not accepted

  • If a keyword not present in VC fields is added, the system shows an error

These keywords represent important fields that should be present in the extracted data.

How validation works

The system checks how many of the configured required keywords are successfully mapped.

  • If the number of matched keywords is equal to or greater than the configured Post-Validation Field Mapping Number, the document is accepted.

  • If the matched keywords are less than the required number, validation fails.

Example: Marksheet Certificate

Description: Above image represents a valid marksheet certificate uploaded by the beneficiary. After OCR extraction and field mapping, post-validation rules are applied to verify that the required fields are successfully mapped and meet the minimum validation criteria.

Post-Validation Rules Applied

Post-Validation Required Fields

These fields must be successfully mapped from the document data.

  • examinationyear

  • classlevel

  • rollnumber

Post-validation checks whether these fields contain valid values after mapping.

Minimum Required Field Count

Example configuration:

  • Required mapped fields count: 2

This means:

  • At least 2 out of the configured fields must contain valid extracted values.

  • If fewer than 2 fields are mapped → validation fails.

Validation Flow Example

Valid Scenario

Mapped fields:

  • examinationyear ✔

  • classlevel ✔

→ 2 fields mapped successfully → ✅ Post-validation passes → Document uploaded successfully!

Invalid Scenario

Mapped fields:

  • examinationyear ✔

→ Only 1 fields mapped → ❌ Post-validation fails → Invalid document type. Required: Marksheet

2.8 Field Mapping Prompt

An optional prompt template can be configured per document type to control how AI extracts and validates data from OCR text.

The following placeholders must be used in the prompt:

  • {extractedText} — OCR-extracted text

  • {schema} — Field schema definition

These placeholders are automatically replaced at runtime. Processing Flow

  1. The system checks vcConfiguration for a custom OCR mapping prompt for the document type

  2. If a custom prompt is found, it is used; otherwise, the default prompt is applied

  3. Placeholders are replaced with actual runtime values

  4. The final prompt is sent to the AI provider for extraction and validation

Default Fallback Behavior If no custom ocrMappingPrompt is configured, the system automatically falls back to the default prompt template. Custom prompts are optional.

2.9 Save Configuration Flow

Document configuration form with all required fields

  1. Admin enters all fields

  1. System validates all fields

  2. Admin saves all configurations

Save All Configurations button highlighted

  1. System persists configurations via API

  2. System displays success confirmation

2.10 Alternative Flows

AF-2.10.1 Add New Configuration

  • Admin clicks Add Configuration

  • New empty configuration block is added

AF-2.10.2 Remove Configuration

  • Admin clicks delete icon

  • Configuration is removed from the list

2.11 Business Rules

  • All document configuration fields marked mandatory must be filled

  • Document Sub Type must be unique

  • VC Fields must be a valid JSON object

  • Every VC field must have:

    • type

3. Map Fields to Documents

Actor: Beneficiary Admin Goal: Create mappings between form fields and document VC fields

Preconditions:

  • Form fields are configured in system

  • Documents are configured with VC schemas

Main Flow:

  1. Admin navigates to Field Mapping Config page

  2. System loads available form fields and document types

Field Mapping Configuration page with loaded data

  1. Admin creates field mapping:

  2. Admin can add multiple document mappings per field

Multiple document mappings for single field

  1. System validates all mappings

  2. Admin saves all mappings

Save All Mappings button highlighted

  1. System persists mapping configuration via API

Success toast with mapping statistics

Alternative Flows:

Business Rules:

  • Each field mapping must have at least one document mapping

  • Document and VC field selections are required

  • Transformation JSON must be valid format

  • Form fields can map to multiple documents/field

4. Default Eligibility

The Default Eligibility feature automatically filters benefits/jobs based on user profile fields (e.g., state, category) and predefined eligibility rules. It ensures that users only see benefits relevant to their profile.

Configuration Source

  • The configuration is stored directly in the beneficiary-backend database settings table under the key:

It is stored as a stringified JSON and read by the Admin Service at runtime.

Config Format i.e value (Stringified JSON Example)

How It Works

Configuration Rules

  • Default eligibility rules define which user profile fields are used to determine eligibility (for example: state).

  • Each rule specifies whether the field should be applied for filtering.

Each rule contains:

  • Key – The user profile field to be matched (e.g., state, category)

  • Apply Flag – Determines whether this rule is active (e.g. true/false)

  • Use User Value Flag – Indicates that the user’s profile value is used for comparison

Matching Process

  • When benefits are fetched for a user, each benefit includes eligibility tags that describe its eligibility criteria.

  • For each active rule:

    • The system compares the user’s profile value with the corresponding benefit eligibility tag.

    • If a benefit does not contain the required eligibility tag, it is excluded.

    • Only benefits where the user’s value matches the benefit’s eligibility criteria are included in My Benefits.

  • Benefits that do not satisfy all active default eligibility rules are excluded from My Benefits.

Resulting User Experience

  • Users see a personalised list of benefits under My Benefits.

  • Benefits that do not match default eligibility rules or are missing required eligibility information are not shown.

Data Flow

Field Management Flow

  1. Load: Fetch existing fields from API

  2. Display: Render fields in table format

  3. Interact: User initiates add/edit/delete

  4. Validate: Client-side validation of input

  5. Submit: API call with validated data

  6. Refresh: Update local state and UI

  7. Feedback: Success/error notification

Document Configuration Flow

  1. Initialize: Load existing configurations

  2. Configure: User enters document details

  3. Validate: JSON schema validation for VC fields

  4. Bulk Save: Submit all configurations together

  5. Persist: Backend storage of configurations

  6. Confirm: Success notification

Field Mapping Flow

  1. Prepare: Load fields and documents

  2. Parse: Extract VC fields from document schemas

  3. Map: User creates field-to-document relationships

  4. Transform: Optional JSON transformation rules

  5. Validate: Ensure all required mappings

  6. Save: Persist mapping configuration

  7. Apply: Mappings available for form processing

Last updated