Admin 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)

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.

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

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

2.3 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.4 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.4.1 VC Field Properties Each field inside vcFields supports the following properties:

Property	Type	Description
type	string	Data type of the field
required	boolean	Whether the field must be present
matching	object	Enables profile-based comparison

Example Document Fields Configuration

{
  "student_name": {
    "type": "string",
    "required": true,
    "matching": {
      "compareWith": "name",
      "matchPercentage": 80
    }
  },
  "district": {
    "type": "string",
    "required": true
  },
  "academic_year": {
    "type": "string",
    "required": false
  }
}

2.4.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.4.3 matching Object – Profile Validation

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

"matching": {
  "compareWith": "profile_field_name",
  "matchPercentage": 80
}

• 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 → Upload rejected

2.5 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

• {expectedDocumentName} — Expected document type name

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.6 Save Configuration Flow

Document configuration form with all required fields

1. Admin enters all fields

1. VC Fields textarea with JSON schema input

2. System validates JSON structure

   
3. Admin saves all configurations

   

Save All Configurations button highlighted

1. System persists configurations via API

2. System displays success confirmation

   

2.7 Alternative Flows

AF-2.7.1 Add New Configuration

• Admin clicks Add Configuration

• New empty configuration block is added

  

AF-2.7.2 Remove Configuration

• Admin clicks delete icon

• Configuration is removed from the list

AF-2.7.3 Invalid VC Fields JSON

• System rejects save

• Validation error is displayed

2.8 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:

defaultEligibility

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

Config Format i.e value (Stringified JSON Example)

"{\"applyFilter\":[{\"key\":\"state\",\"isApply\":true,\"useUserValue\":true},{\"key\":\"category\",\"isApply\":true,\"useUserValue\":true}]}"

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