Staff Details — Forms
Forms — Staff Details
UX / forms specification · slug
staff· 2026-05-02 Companion todocs/blueprints/staff.md. Reading order: Onboarding → Profile → Medical → Qualifications → Vedic Capability → Training → Experience → Hierarchy → SWOT → Pay → Identity Documents → Exit.
This document specifies every screen-level form in the Staff Details module. Every Sanskrit-bearing field (gothra, sutra, shakha, capability slugs) must round-trip VijayaDV PUA characters intact — UI inputs must use lang="sa" and avoid Unicode normalization. Identity-document fields are encrypted at rest and require a second-key authoriser before commit; every read writes an audit_events row carrying the requester and reason.
Section 1 — Onboarding
Workflow note: A new joinee — be it an archaka, kitchen sevadar, instructor, or admin clerk — enters the system through the multi-step Onboarding Wizard. The wizard creates exactly one canonical members row (or reuses an existing one if the person was previously a donor or volunteer), one memberships row, one staff_profiles row, and zero-or-more staff_qualifications rows in a single transaction. The HR officer can save a draft after any step; the wizard reopens at the last completed step. Identity-document upload and pay-structure entry are deliberately excluded from this wizard — they happen in dedicated workflows after the staff_code is generated, because both require a second authoriser.
Form 1.1 — Staff Onboarding Wizard · Step 1: Personal
Purpose: Capture biographical data that lands on the canonical members row.
Who fills: HR officer or tenant-admin, once at hire.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Existing member lookup | Search (typeahead) | No | matches members by name / phone / email | — | If found, skip rest of step and reuse member_id |
| Full name | Text (Devanagari + Latin) | Yes | min 2 chars, max 127 | — | Use VijayaDV-rendered Sanskrit if available |
| Salutation | Select | No | Sri / Smt / Brahmasri / Vidwan / Dr / Other | Sri | Honorific prefix |
| Gender | Radio | Yes | Male / Female / Other / Prefer not to say | — | |
| Date of birth | Date | Yes | <= today, >= 1900-01-01 | — | Used to derive age at joining |
| Blood group | Select | No | A+ / A- / B+ / B- / AB+ / AB- / O+ / O- / Unknown | Unknown | Surfaced in medical emergencies |
| Mobile | Tel | Yes | E.164; India default +91 | — | Becomes login if email-link auth used |
| No | RFC 5322 | — | Required if Google OAuth login planned | ||
| Nakshatram | Select | No | 27 nakshatram catalog (lookup) | — | Used by Comms anniversary greetings |
| Gothra | Combo (datalist) | No | Bharadwaja / Vasishtha / Kashyapa / Atri / Vishvamitra / Jamadagni / Gautama / Angirasa / Bhrigu / Other (free text) | — | Type to add tenant-specific gothra |
| Permanent address | Textarea | Yes | min 10 chars | — | Used for postal Comms |
| Photo | File upload | No | jpg/png, max 2 MB, 1:1 cropped to 600×600 | — | Stored in members.photo |
Submit action: "Next →" validates and stages a draft members payload in session. No DB write yet.
Related forms: Step 2 follows; "Back" returns to lookup.
Form 1.2 — Staff Onboarding Wizard · Step 2: Role & Branch
Purpose: Decide where this person sits in the institutional structure. Who fills: HR officer.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Role category | Select | Yes | archaka / admin / kitchen / grounds / security / sevadar / instructor / other | — | Determines downstream form variants |
| Designation | Text | No | max 127 chars | — | e.g. Pradhana Archaka, Annadana Coordinator |
| Department | Select / Text | No | from tenant department list + "Other" | — | |
| Branch | Select | Yes | active branches in this tenant | tenant default | Posting location |
| Employment type | Select | Yes | permanent / contract / sambhavana / volunteer-paid | permanent | Drives payroll & tax routing |
| Date of joining | Date | Yes | <= today + 90 days | today | Probation clock starts here |
| Probation period (months) | Number | No | 0–24 | 6 | Auto-fills date_of_confirmation |
| Allocate accommodation room | Combo | No | rooms with vacancy in selected branch | — | Optional; can be assigned later via Asset Mgmt |
Submit action: "Next →" stages role+branch payload. If role_category=archaka, Step 3 expands to include Vedic identity sub-section. Related forms: Step 3 (Qualifications) follows.
Form 1.3 — Staff Onboarding Wizard · Step 3: Qualifications
Purpose: Record degrees, Vedic training, and (for archakas) ritual capabilities. Who fills: HR officer; archaka entries reviewed by Pradhana Archaka.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Add qualification (repeatable) | Repeating block | At least 1 | up to 20 rows | — | Each row: kind, title, institution, year, grade |
| Qualification kind | Select | Yes (per row) | academic / professional / vedic / language | academic | "vedic" reveals capability checklist |
| Title | Text | Yes | max 255 | — | e.g. MA Sanskrit, Ghanapatha, CA |
| Institution | Text | No | max 255 | — | |
| Year obtained | Number | No | 1940–current year | — | |
| Grade / class | Text | No | max 48 | — | First class / 8.6 CGPA / Distinction |
| Vedic identity (archaka only) | — | — | — | — | Section appears only if role=archaka |
| Sutra | Combo | Yes for archaka | Apastamba / Bodhayana / Hiranyakeshi / Aswalayana / Drahyayana / Other | — | Determines kalpa-sutra lineage |
| Shakha | Select | Yes for archaka | Krishna Yajurveda / Shukla Yajurveda / Rigveda (Shakala) / Samaveda (Kauthuma) / Samaveda (Ranayaniya) / Atharvaveda | — | Veda-shakha affiliation |
| Vedic capabilities | Multi-select checkboxes | No | Sandhya Vandanam / Agnikaryam / Rudra / Chamaka / Mahanayasam / Temple Vastu / Kalyanotsavam / Brahma Yajna / Deva Yajna | — | See Form 4.2 for full taxonomy |
Submit action: "Next →" stages qualifications array. Related forms: Step 4 (Review) follows; Form 4.2 manages capabilities post-onboarding.
Form 1.4 — Staff Onboarding Wizard · Step 4: Review & Submit
Purpose: Final review before atomic commit. Who fills: HR officer.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Read-only summary card | Display | — | renders Steps 1–3 | — | All entered data |
| Send welcome email | Checkbox | No | requires email on Step 1 | true | Triggers Comms welcome template |
| Initial supervisor | Select | No | active staff in same branch | — | Sets supervisor_id; can be deferred |
| HR officer remarks | Textarea | No | max 2000 chars | — | Internal note, written to audit_events |
| Confirmation | Checkbox | Yes | "I confirm details are accurate" | false | Required to enable Submit |
Submit action: Calls POST /api/staff/onboard. Server runs onboard_staff(...) in one transaction: members → memberships → sequence_numbers (staff_code) → staff_profiles → staff_qualifications → audit_event → enqueue welcome email. On success, redirects to /staff/{id} detail.
Related forms: Triggers Form 5.1 (Pay Structure) and Form 11.1 (Identity Document Upload) as deferred follow-ups.
Section 2 — Personal & Medical
Workflow note: Personal data lives on the members row and is editable from the Personal tab on the staff detail page. Medical data lives on staff_profiles directly — it is staff-scoped because medical conditions can change with employment (occupational asthma, work-related stress) and must be surfaced to the supervisor and the on-site emergency contact list. Both forms write to audit_events. Medical-condition flags appear in the daily roster summary; the emergency contact field is the single field a security guard or visiting paramedic can reach without authentication via a printed laminated card.
Form 2.1 — Personal Profile Edit
Purpose: Update biographical and contact data on the canonical members row. Who fills: Staff self-service or HR officer; on change of address, marriage, photo refresh.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Full name | Text | Yes | min 2, max 127 | current | Legal name as on Aadhaar |
| Salutation | Select | No | Sri / Smt / Brahmasri / Vidwan / Dr / Other | current | |
| Date of birth | Date | Yes | locked after first save (HR-only edit) | current | DOB changes require admin justification |
| Blood group | Select | No | 8 ABO/Rh + Unknown | current | |
| Mobile (primary) | Tel | Yes | E.164 | current | OTP verified on change |
| No | RFC 5322 | current | OTP verified on change | ||
| Permanent address | Textarea | Yes | min 10 | current | |
| Current address (if different) | Textarea | No | min 10 | — | |
| Marital status | Select | No | Single / Married / Widowed / Sannyasi / Brahmachari / Other | current | |
| Spouse name | Text | No | shown only if Married | — | Goes into members.spouse |
| Father's name | Text | No | max 127 | current | |
| Mother's name | Text | No | max 127 | current | |
| Family members (repeatable) | Block | No | up to 12 rows: name, relation, dob | — | Children, dependents |
| Photo | File upload | No | jpg/png, max 2 MB, square crop | current | Replaces members.photo |
Submit action: PATCH /api/members/{member_id}. Writes audit_event staff.personal.changed with diff payload.
Related forms: Form 2.2 (Medical) for health flags; Form 11.1 (Identity Documents) for Aadhaar/PAN.
Form 2.2 — Medical Conditions Tracker
Purpose: Record long-term medical conditions and the emergency contact line used for incident response. Who fills: Staff self-service (with HR confirmation for sensitive flags) or HR; reviewed annually.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Diabetes | Checkbox | No | — | false | Type 1 / 2 captured in notes |
| Hypertension (BP) | Checkbox | No | — | false | |
| Asthma | Checkbox | No | — | false | |
| Heart ailment | Checkbox | No | — | false | Includes prior stent / valve / arrhythmia |
| Other conditions | Textarea | No | max 1000 | — | Epilepsy, allergies, ongoing treatment |
| Current medications | Textarea | No | max 1000 | — | Drug name + dose + frequency, one per line |
| Drug allergies | Text | No | max 255 | — | e.g. penicillin, sulfa |
| Emergency contact name | Text | Yes | max 127 | — | Primary next-of-kin |
| Emergency contact phone | Tel | Yes | E.164 | — | Reachable 24×7 |
| Emergency contact relation | Text | Yes | max 63 | — | Spouse / Father / Brother / etc |
| Treating physician | Text | No | max 127 | — | Optional |
| Last health check-up date | Date | No | <= today | — | Used for annual reminder |
| Medical info accessible to | Multi-select | Yes | HR / Branch supervisor / On-duty security / Pradhana Archaka | HR + supervisor | Privacy scoping |
Submit action: PATCH /api/staff/{staff_id} with medical fields. Audit event staff.medical.changed (records that it changed, not the diff payload — privacy). Triggers reprint of branch emergency-contact roster.
Related forms: Form 4.1 / 4.2 (capabilities — heart conditions may inform suitability for Mahanayasam fasts).
Section 3 — Qualifications & Capabilities
Workflow note: Qualifications are append-only after the wizard. A new degree, language certificate, or professional course is added with the "Add qualification" button on the Qualifications tab. Each entry has a verified flag — set by a designated reviewer (Pradhana Archaka for vedic kind, Principal for academic, HR for professional). The Vedic capability matrix is treated specially: it is not a qualification list but a checklist persisted as a single JSON column on the archaka's vedic-kind qualification row, so it can be queried by Events Planner with one indexed lookup.
Form 3.1 — Education & Qualifications Edit
Purpose: Add or update one degree / certification entry. Who fills: Staff self-service for new attainments; HR for backfill; reviewer for verification.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Kind | Select | Yes | academic / professional / vedic / language | academic | "vedic" reveals capability section |
| Title | Text | Yes | max 255 | — | e.g. MA Sanskrit, Ghanapatha, CA Inter |
| Institution | Text | No | max 255 | — | University / pathashala / certification body |
| Year obtained | Number | No | 1940–current | — | |
| Grade / class | Text | No | max 48 | — | First class / 8.6 CGPA / Vidvan |
| Specialisation | Text | No | max 127 | — | e.g. Vyakarana, Forensic Accounting |
| Certificate scan | File upload | No | pdf/jpg/png, max 5 MB | — | Stored as identity_document with doc_type=certificate |
| Verified | Checkbox | No (reviewer only) | locked from staff | false | Reviewer toggles |
| Verified by | Auto | — | server-set on verify | — | |
| Verified at | Auto | — | server-set on verify | — | |
| Notes | Textarea | No | max 1000 | — |
Submit action: POST /api/staff/{staff_id}/qualifications for new; PATCH /api/staff/qualifications/{qid} for edit; PATCH /api/staff/qualifications/{qid}/verify for reviewer toggle.
Related forms: Form 3.2 manages the vedic capability checklist on a single row.
Form 3.2 — Vedic Capability Checklist (Archakas)
Purpose: Record which rituals an archaka is competent to perform — the matrix Events Planner reads when assigning rituals. Who fills: Pradhana Archaka or designated guru; reviewed at confirmation and annually.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Gothra | Combo | No | Bharadwaja / Vasishtha / Kashyapa / Atri / Vishvamitra / Jamadagni / Gautama / Angirasa / Bhrigu / Other | from members | Read-only mirror; edit on Form 2.1 |
| Sutra | Combo | Yes | Apastamba / Bodhayana / Hiranyakeshi / Aswalayana / Drahyayana / Other | — | Determines kalpa-sutra |
| Shakha | Select | Yes | Krishna Yajurveda / Shukla Yajurveda / Rigveda (Shakala) / Samaveda (Kauthuma) / Samaveda (Ranayaniya) / Atharvaveda | — | Veda-shakha |
| Pravara count | Select | No | Eka / Tri / Pancha / Sapta | Tri | Pravara depth used for sankalpa |
| Daily nitya | — | — | — | — | Section header |
| Sandhya Vandanam | Checkbox | No | — | false | Tri-sandhya competence |
| Agnikaryam | Checkbox | No | — | false | Aupasana / homa daily |
| Brahma Yajna | Checkbox | No | — | false | Daily Veda recitation |
| Deva Yajna | Checkbox | No | — | false | Daily devata pooja |
| Major recitations | — | — | — | — | Section header |
| Rudra (Namaka) | Checkbox | No | — | false | Sri Rudram chanting |
| Chamaka | Checkbox | No | — | false | Chamakam chanting |
| Mahanayasam | Checkbox | No | — | false | Pre-Rudram nyasa with anga-nyasa |
| Purusha Suktam | Checkbox | No | — | false | |
| Sri Suktam | Checkbox | No | — | false | |
| Major rituals | — | — | — | — | Section header |
| Temple Vastu | Checkbox | No | — | false | Vastu-shanti and prati-stha rituals |
| Kalyanotsavam | Checkbox | No | — | false | Marriage of the deity / human kalyanam |
| Maha Ganapati Homa | Checkbox | No | — | false | |
| Satyanarayana Vratam | Checkbox | No | — | false | |
| Punya Aha Vachanam | Checkbox | No | — | false | Auspicious day declaration |
| Antyeshti rites | Checkbox | No | — | false | Funeral rites — sensitive flag |
| Other capability (free) | Multi-tag | No | tenant-extensible | — | e.g. dakshinamurti_pooja for Smarta tenants |
| Last reviewed by | Display | Auto | reviewer name | — | |
| Last reviewed on | Display | Auto | date | — | Annual review reminder fires 11 months in |
Submit action: POST /api/staff/{staff_id}/vedic-capabilities upserts the single vedic-kind StaffQualification row's vedic_capabilities JSON list. Audit event staff.vedic_capabilities.changed. Events Planner consumers are notified.
Related forms: Form 4.1 (Training) records new capability acquisition; find_archakas_for_ritual API consumes this matrix.
Section 4 — Training & Experience
Workflow note: Training and experience are captured separately. Training records are internal or sponsored learning episodes (a Veda parayana camp, a fire-safety course, an accounts software workshop) that happened during this employment. Experience records are prior roles at other institutions, captured for context and reference checks. Both are append-only timelines.
Form 4.1 — Training Record Add
Purpose: Log a training programme attended during employment. Who fills: HR or staff self-service; verified by HR.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Programme name | Text | Yes | max 255 | — | e.g. Bhagavad Gita Parayana Shibir |
| Provider | Text | No | max 255 | — | Internal pathashala or external body |
| Delivery | Select | Yes | internal / external / online / mentorship | external | |
| Start date | Date | No | — | — | |
| End date | Date | No | >= start | — | |
| Duration (hours) | Number | No | 1–2000 | — | Auto-calc from dates if both given |
| Outcome / certification | Text | No | max 255 | — | Pass / certificate awarded |
| Certificate scan | File upload | No | pdf/jpg/png, max 5 MB | — | |
| Cost (INR) | Number | No | >= 0 | 0 | If sponsored by institution |
| Sponsored by institution | Checkbox | No | — | true | Drives reimbursement workflow |
| Capability unlocked | Multi-select | No | links to vedic_capability_catalog | — | Auto-toggles those capabilities on Form 3.2 |
| Notes | Textarea | No | max 1000 | — |
Submit action: POST /api/staff/{staff_id}/training. If "Capability unlocked" is set, the Vedic capability checklist (3.2) is updated atomically.
Related forms: Form 3.2 (capabilities), Form 5.1 (pay structure may reflect post-training increment).
Form 4.2 — Past Experience Entry
Purpose: Record a prior role at another institution. Who fills: HR officer at hire (often pre-onboarding); editable.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Institution name | Text | Yes | max 255 | — | Where they worked |
| Designation | Text | No | max 255 | — | Role held |
| Start date | Date | No | — | — | |
| End date | Date | No | >= start | — | Blank if "current" |
| Currently working there | Checkbox | No | — | false | If true, end_date stays null |
| Reason for leaving | Text | No | max 255 | — | |
| Reference contact | Text | No | name + phone in free text | — | For verification |
| Reference verified | Checkbox | No (HR only) | — | false | HR toggles after call |
| Notes | Textarea | No | max 1000 | — |
Submit action: POST /api/staff/{staff_id}/experience.
Related forms: Surfaces in Onboarding wizard step 3; can be added later from the Experience tab.
Section 5 — Hierarchy & Reviews
Workflow note: Every active staff member has zero or one supervisor (supervisor_id). The hierarchy renders as a tree on /staff/hierarchy. SWOT reviews are submitted by the supervisor at a defined cadence (default annual, optionally quarterly for archakas in confirmation period). The review is private to supervisor + HR until the staff member acknowledges it; acknowledgement opens the review for staff self-service viewing thereafter.
Form 5.1 — Hierarchy Assignment
Purpose: Set or change a staff member's reporting line. Who fills: HR or department head.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Staff member | Display | — | locked from URL context | current | Subject of the change |
| New supervisor | Select (typeahead) | Yes | active staff in same tenant; cannot be self or descendant | current | Cycle prevention enforced server-side |
| Effective from | Date | Yes | <= today + 30 days | today | |
| Reason | Textarea | No | max 500 | — | e.g. branch reorganisation, promotion |
| Notify both parties | Checkbox | No | — | true | Triggers Comms |
| Reassign direct reports? | Radio | No | Keep / Move to new supervisor / Move to old supervisor's manager | Keep | Cascade decision |
Submit action: PATCH /api/staff/{staff_id} with new supervisor_id. Server validates no cycle (walks ancestors). Audit event staff.hierarchy.changed. Hierarchy tree cache invalidated.
Related forms: Form 5.2 (SWOT) is filed by supervisor.
Form 5.2 — SWOT Review Form
Purpose: Periodic structured review by supervisor. Captures growth conversation, not just rating. Who fills: Direct supervisor; co-signed by department head for senior staff.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Staff member | Display | — | locked | current | |
| Period label | Text | Yes | max 63 | "FY{yyyy} {Q?}" | e.g. "FY2025-26 Q3" |
| Review date | Date | Yes | <= today | today | |
| Reviewer | Auto | — | server-set to current user | — | |
| Co-reviewer (optional) | Select | No | other staff in tenant | — | Department head if senior |
| Strengths | Textarea | No | max 4000 | — | What is going well — be specific |
| Weaknesses | Textarea | No | max 4000 | — | Areas for improvement, framed constructively |
| Opportunities | Textarea | No | max 4000 | — | Growth paths — new capability, role, branch |
| Threats | Textarea | No | max 4000 | — | Risks — health, family, external offers, attrition risk |
| Development actions | Textarea | No | max 4000 | — | Concrete agreed steps with deadlines |
| Overall rating | Radio | No | 1 (Below expectations) – 5 (Outstanding) | 3 | Used in attrition KPIs |
| Recommend pay revision | Checkbox | No | — | false | Routes to Form 5.3 if checked |
| Visible to staff after acknowledgement | Checkbox | No | — | true | Default open culture; uncheck only with HR consent |
Submit action: POST /api/staff/{staff_id}/swot. Audit event staff.swot.created. Comms nudge sent to staff member to acknowledge. Acknowledgement is a separate PATCH /api/staff/swot/{review_id}/acknowledge action with no fields beyond a confirmation checkbox.
Related forms: Form 5.3 (Pay Structure Editor) if increment is recommended; Form 4.1 (Training) for development actions.
Form 5.3 — Pay Structure Editor
Purpose: Author a new versioned pay envelope. Closes the prior structure automatically. Who fills: HR finance officer or tenant-admin; approved by trustee for senior staff.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Effective from | Date | Yes | >= today | first of next month | New structure starts here; prior auto-closed at this minus one day |
| Pay kind | Select | Yes | salary / sambhavana / stipend / honorarium | inherit prior | Routes payroll engine differently |
| Currency | Select | Yes | INR / USD | INR | |
| PF applicable | Checkbox | No | — | inherit | EPF deduction |
| ESI applicable | Checkbox | No | — | inherit | ESI deduction |
| TDS section | Select | No | 192 (salary) / 194J (professional) / Exempt | 192 | |
| Components (repeatable, drag-to-reorder) | — | — | — | — | Each component below |
| Component code | Text | Yes (per row) | max 40, e.g. BASIC, HRA, FOOD, SAMBHAVANA_BASE | — | Used in payslip and formula refs |
| Component type | Select | Yes (per row) | earning / deduction / perk_in_kind | earning | |
| Label (display) | Text | Yes (per row) | max 255 | — | Human label on payslip |
| Amount (INR) | Number | Yes (per row) | 0 if formula provided | 0 | |
| Formula | Text | No (per row) | references other component codes | — | e.g. 0.4 * BASIC |
| Taxable | Checkbox | No (per row) | — | true | Affects Form 16 |
| Footer | — | — | — | — | |
| Reason for change | Textarea | Yes | max 500 | — | Promotion, annual increment, role change |
| Approved by | Select | Yes | tenant-admin or trustee | current user if eligible | Recorded on audit_event |
| Notes | Textarea | No | max 1000 | — | Internal only |
Submit action: POST /api/staff/{staff_id}/pay-structure. Server closes prior active structure (sets effective_to = new effective_from - 1 day), inserts the new structure with components in one transaction. Audit event staff.pay.changed carrying (old_total, new_total, reason, approved_by). Vitta payroll picks up the new structure on the next payroll run.
Related forms: Form 5.2 (SWOT) often triggers this; viewable on Pay tab.
Section 6 — Identity Documents & Exit
Workflow note: Identity documents (Aadhaar, PAN, passport, driving licence, bank passbook) are stored encrypted with envelope encryption — a per-tenant DEK wrapped by a project-level KEK in GCP KMS. The UI never displays the raw value; it displays a masked surface ("XXXX XXXX 1234"). Decryption requires explicit "Reveal" action that opens a reason-prompt dialog and writes an audit_events row capturing requester, reason, and timestamp. Initial upload requires a second authoriser (two-key) drawn from the tenant-admin pool. Exit closes the staff_profile, closes the active pay structure, suspends the membership, and schedules identity-document purge after the DPDP retention window (5 years).
Form 6.1 — Identity Document Upload
Purpose: Upload an identity document. Encrypted on write. Two-key approval required before commit. Who fills: HR officer at onboarding or on document refresh; second key by tenant-admin.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Document type | Select | Yes | Aadhaar / PAN / Passport / Driving Licence / Voter ID / Bank Passbook / Other | — | Determines validation regex |
| Document number | Text | Yes | regex per type (Aadhaar 12 digits / PAN 10 alpha-num / etc) | — | Encrypted at rest. Never logged in plaintext |
| Issued on | Date | No | <= today | — | |
| Expires on | Date | No | > issued_on | — | Drives expiry-reminder cron |
| Issuing authority | Text | No | max 127 | — | UIDAI / IT Dept / RPO / etc |
| Document scan | File upload | Yes | pdf/jpg/png, max 5 MB | — | Encrypted same as the number |
| Bank name (if Bank Passbook) | Text | Conditional | required for bank | — | |
| IFSC (if Bank Passbook) | Text | Conditional | 11 chars, regex | — | |
| Account number (if Bank Passbook) | Text | Conditional | encrypted | — | |
| Reason for upload / refresh | Textarea | Yes | max 500 | — | Goes into audit_event |
| Second authoriser | Select | Yes | tenant-admin users (not the requester) | — | Two-key requirement |
| Confirmation | Checkbox | Yes | "I confirm consent obtained from staff" | false | DPDP consent record |
Submit action: POST /api/staff/{staff_id}/identity-documents. Server runs encrypt_identity_document(...): envelope-encrypts payload via GCP KMS DEK, stores ciphertext + key_version + masked_value, creates a pending_writes row, and notifies the second authoriser via Comms. The row becomes committed only after the second authoriser approves. Audit event staff.identity.uploaded (no payload, just metadata).
Related forms: Decrypt action (separate POST /api/staff/identity-documents/{doc_id}/decrypt) returns plaintext once with reason logged.
Form 6.2 — Staff Exit Form
Purpose: Process a staff exit — voluntary or involuntary — and trigger downstream cleanup. Who fills: HR officer; approved by tenant-admin.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Date of exit | Date | Yes | <= today + 90 | — | Last working day |
| Exit type | Select | Yes | Resignation / Retirement / End of contract / Termination / Sannyasa / Demise / Other | — | Drives Comms tone |
| Reason (free text) | Textarea | Yes | max 1000 | — | Detail; written to audit_event |
| Notice period served (days) | Number | No | 0–365 | — | For policy compliance |
| Final settlement status | Select | Yes | Pending / Computed / Paid / NA | Pending | Vitta routes settlement |
| Final settlement amount (INR) | Number | No | computed by Vitta | — | Read-only display; HR cannot edit |
| Outstanding advance (INR) | Number | No | from imprest module | — | Read-only |
| Asset return checklist | Repeating block | No | checkboxes per asset issued | — | ID card, laptop, keys, books |
| Identity documents handling | Radio | Yes | Retain (5y per DPDP) / Purge immediately on staff written request | Retain | Default per DPDP guidance |
| Reactivation allowed | Checkbox | No | — | true if voluntary | If false, blocks future onboarding for same member |
| Exit interview link | URL | No | external form URL | — | |
| Approved by | Select | Yes | tenant-admin | — | Audit recorded |
| Final remarks | Textarea | No | max 2000 | — |
Submit action: POST /api/staff/{staff_id}/exit. Server runs soft_exit_staff(...): sets employment_status='exited', date_of_exit, exit_reason; closes active pay structure; sets memberships.status='suspended'; schedules identity-document purge per DPDP window; emits audit_event staff.exited; notifies Vitta to compute final settlement.
Related forms: Form 5.3 (Pay Structure) is auto-closed; Members Suite Form 1.1 (Categorize) auto-removes staff_index category.