Candidate Admission Case
Epic summary
The Candidate Admission Case is the central screen for one candidate. It brings together every record needed to understand the candidate’s position without giving every user permission to change everything.
The case follows the candidate across rounds and revisions. It preserves earlier allotments, reporting events, decisions, and movement rather than replacing them with the latest status.
Actors and access
Each role sees and edits only the sections required for its work.
| Actor | Main case access |
|---|---|
| Admission Clerk | Identity, contact, reporting, and document receipt |
| Document Scrutiny Officer | Documents, custody, and deficiencies |
| Admission Scrutiny Committee Member | Eligibility evidence and findings |
| Head of Department or PG Coordinator | Assigned programme and academic review |
| Accounts Officer | Fees, payments, refunds, and financial clearance |
| Medical Officer | Restricted medical-fitness section |
| Legal/Bond Officer | Bond and legal section |
| Admission Nodal Officer | Operational summary and workflow coordination |
| Authorised Dean/Principal | Decision summary and supporting evidence |
| Student Section Officer | Approved admission and enrolment handoff |
| Candidate | Own submissions and published outcomes only |
| Internal Auditor | Read-only access with sensitive-field controls |
Screen structure and information captured
The candidate case is the cross-epic dossier. It contains a fixed summary header and role-filtered tabs. Users update only fields owned by their assigned office or capability.
Case summary header
| Field group | Information shown |
|---|---|
| Case identity | Case number, candidate ID, name, photograph, date of birth, contact, and identity-match status |
| Organisational context | Governance entity, institution, department where relevant, programme offering, and cycle |
| Actionable allotment | Authority, process, round, allotment number, programme, quota, allotted category, rank, and deadlines |
| Case states | Reporting, documents, eligibility, finance, medical, programme, bond/legal, decision, joining, and enrolment states |
| Time controls | Reporting deadline, joining deadline, statutory cutoff, remaining time, and blocking expiry |
| Current owner | Pending task, assigned office/person, due time, and escalation state |
Case tabs and owned fields
| Tab | Principal fields |
|---|---|
| Allotments | Complete authority and round history, source versions, upgrades, cancellations, and actionable flag |
| Reporting | Reporting events, identity comparison, acknowledgement, contact confirmation, and received documents |
| Documents | Checklist, identifiers, original/copy status, findings, deficiencies, and custody |
| Eligibility | Rule-by-rule result, evidence used, recommendation, conditions, and override history |
| Clearances | Finance, medical, programme, and bond/legal outcomes with responsible officers and timestamps |
| Decision and joining | Prepared recommendation, final decision, reason, authority, letter, joining event, and declarations |
| Movement and exit | Upgrade, withdrawal, resignation, cancellation, relieving, refund, and document return |
| Enrolment handoff | Person/student match, programme enrolment, university submission, and handoff errors |
| Communication | Template, recipient, channel, subject, content, attachments, delivery state, and response due date |
| Timeline and audit | Immutable event sequence with actor, entity scope, timestamp, source, and before/after values |
Sensitive medical, identity, and internal-review fields are filtered independently of general case access.
Use case 1: Understand the candidate’s current position
As an Admission Nodal Officer
I want to see a clear summary of the candidate’s case
So that I know what has happened and what must happen next.
Acceptance criteria
- The header shows candidate identity, actionable allotment, programme, seat pool, authority, round, and deadlines.
- The screen shows separate allotment, reporting, document, eligibility, finance, medical, bond, decision, joining, and enrolment states.
- The next required action and responsible role are visible.
- Blocking deficiencies and cutoff risks are prominent.
- Earlier allotments and superseded states remain available in a chronological history.
- The displayed information respects field-level and entity-level access.
Negative cases and alternate flows
- No actionable allotment: Show the historical case but disable admission actions.
- Conflicting current allotments: Display both and require conflict resolution; do not choose silently.
- Restricted section: Show the clearance outcome where permitted without exposing restricted details.
- Possible duplicate person: Block enrolment handoff until identity linkage is resolved.
Use case 2: Navigate the complete dossier
As an assigned Admission Committee member or specialist officer
I want to move between sections without losing context
So that I can complete my assigned work accurately.
Acceptance criteria
- The case provides consistent sections for profile, allotments, reporting, documents, eligibility, clearances, decisions, movement, communications, and audit.
- Opening a task from a work queue takes the user directly to the relevant section.
- The candidate identity and current allotment remain visible while navigating.
- Unsaved work is protected before the user leaves a section.
- Each section shows its owner, status, and last update.
Negative cases and alternate flows
- Section unavailable to role: Do not reveal hidden fields through URLs, downloads, or search.
- Concurrent edit: Warn the user and prevent silent overwriting of another officer’s update.
- Record locked: Permit viewing but explain why editing is unavailable.
Use case 3: Review the case timeline
As an Internal Auditor
I want to see the chronological case history
So that I can reconstruct the admission decision.
Acceptance criteria
- The timeline includes imports, reporting, document actions, deficiencies, clearances, approvals, joining, movement, and enrolment.
- Every event identifies the user or service, time, entity scope, source record, and reason where applicable.
- Revised records link to the earlier version.
- Generated letters and source files can be opened when the auditor has permission.
- Audit events cannot be edited from the case screen.
Negative cases and alternate flows
- Sensitive evidence: Mask or withhold content while retaining the existence and authorised outcome of the event.
- Export requested: Require a separate export capability and log the export.
- System-generated event: Identify the service and rule that produced it.
Use case 4: Communicate from the case
As an Admission Nodal Officer
I want to send a case-related communication
So that the candidate receives a clear, recorded instruction or decision.
Acceptance criteria
- The user selects an approved template appropriate to the case state.
- Candidate and admission details are populated from the current case.
- The user previews the message before sending.
- The communication channel, delivery outcome, content version, and sender are retained.
- Internal notes and restricted findings are not inserted into candidate messages.
Negative cases and alternate flows
- No verified contact: Require contact correction or another approved channel.
- Delivery failure: Retain the failed attempt and create a follow-up task.
- Case changed before send: Warn the user and refresh time-sensitive content.
Success outcome
An authorised user can understand and reconstruct the entire admission case while every specialist remains confined to the information and actions needed for their role.