Student Enrolment Handoff
Epic summary
The Student Enrolment Handoff epic is the controlled boundary between Admissions and the learner’s ongoing academic record.
It creates or links the person and student, assigns the correct programme, batch, speciality, and regulation version, and starts the university-enrolment process. Admissions retains the historical intake evidence; the student and programme modules own ongoing academic life.
Actors and access
| Actor | Access |
|---|---|
| Admission Nodal Officer | Initiates and monitors the handoff |
| Student Section Officer | Creates or links records and completes enrolment tasks |
| Authorised Dean/Principal | Views the final handoff outcome |
| Head of Department or PG Coordinator | Views admitted learners in assigned programmes |
| System Administrator | Resolves technical failures without changing business decisions |
| Candidate | Receives published student or enrolment identifiers |
| Internal Auditor | Read-only handoff and identity-linkage history |
Screen structure and data captured
The workspace contains Handoff Readiness, Person Match, Student Record, Programme Enrolment, and University Registration. Admission evidence is read-only; the Student Section records only the new student and enrolment identifiers needed for the next lifecycle stage.
Handoff-readiness fields
| Field group | Information shown |
|---|---|
| Admission context | Case, institution, cycle, programme offering, allotment, quota, decision, and joining event |
| Required completion | Admission approved, joined, no blocking movement, finance/bond condition satisfied, and documents complete |
| Academic assignment | Admission batch, programme type, speciality, regulation version, and starting stage |
| Blocking issues | Duplicate identity, incomplete clearance, cancelled allotment, missing batch/version, or university-data deficiency |
Person and student fields
| Field | Entry type | Required | Meaning and validation |
|---|---|---|---|
| Person-match candidates | System suggested | Yes | Existing identities matched by verified identifiers and demographics |
| Match decision | Selected | Yes | Link existing person, create new person, or send for identity review |
| Verified identity details | Inherited | Yes | Name, date of birth, gender, identifiers, photograph, contact, and address |
| Student number | Generated/entered | Yes | Unique institutional identifier under configured numbering rules |
| Student status | System controlled | Yes | Pre-enrolled, Active, or Hold pending required completion |
| Category/disability flags | Inherited/confirmed | Conditional | Transferred under field permissions and applicable consent controls |
Programme-enrolment fields
| Field | Entry type | Required | Meaning and validation |
|---|---|---|---|
| Programme offering | Inherited | Yes | Final admitted offering; cannot be changed during handoff |
| Admission batch | Inherited/selected | Yes | Batch configured in the cycle |
| Regulation version | Inherited | Yes | Version pinned from the cycle offering |
| Entry stage | System selected | Yes | Phase, residency year, internship, or milestone start |
| Enrolment date | Inherited | Yes | Based on completed admission/joining policy |
| Roll/registration placeholder | Generated | No | Used until university number is received |
| Cohort/group assignment | Selected/generated | No | Initial cohort and provisional grouping where applicable |
University-registration fields
| Field | Entry type | Meaning |
|---|---|---|
| Affiliating/examining university | Inherited | Relationship configured for the programme offering |
| Registration return format | Selected | Version required for the university and session |
| Submission batch/reference | Generated | File/batch and institutional reference |
| University application/registration number | Entered/imported | Number assigned by the university |
| Submission/acknowledgement dates | Entered/integration | Transmission and response evidence |
| University outcome | Selected/imported | Submitted, accepted, returned, rejected, or registered |
| Return reason and correction | Entered | Required when returned or rejected |
Use case 1: Prepare the enrolment handoff
As an Admission Nodal Officer
I want to send an approved and joined case for enrolment
So that only valid admissions enter the student system.
Acceptance criteria
- The case must be approved and joined.
- The cutoff, movement, and cancellation checks are repeated before handoff.
- The programme offering, batch, speciality, and regulation-version assignment are complete.
- The handoff package identifies the authoritative admission data and any permitted student-profile updates.
- Initiation records the admission version used.
Negative cases and alternate flows
- Not joined: Prevent handoff.
- Pending cancellation or upgrade: Hold the handoff until resolved.
- Missing regulation version: Return the case to configuration rather than creating an incomplete enrolment.
Use case 2: Match or create the person and student
As a Student Section Officer
I want to match the admitted candidate to the correct person
So that the institution does not create duplicate identities.
Acceptance criteria
- The system searches existing person and student records using approved identifiers.
- Strong matches are presented for confirmation rather than automatically merged without evidence.
- A new person is created only when no valid existing record is found.
- Previous applicant, student, intern, or employee relationships can remain linked to the same person.
- The identity-link decision is audited.
Negative cases and alternate flows
- Multiple possible matches: Route to identity resolution.
- Existing active student conflict: Prevent duplicate active enrolment and require review.
- Incorrect prior linkage: Correct through a controlled unlink/relink process with history.
Use case 3: Create programme enrolment
As a Student Section Officer
I want to create the learner’s programme enrolment
So that academic modules receive the correct starting context.
Acceptance criteria
- The enrolment contains institution, programme, speciality, admission batch, start date, and regulation version.
- A unique institutional student identifier is assigned according to policy.
- The record links back to the final admission and seat pool.
- Downstream access or service requests are generated only after successful creation.
- Repeating the handoff is idempotent and does not create a duplicate student or enrolment.
Negative cases and alternate flows
- Student-number generation failure: Keep the handoff Pending and retry without duplicating the person.
- Programme no longer active: Stop and require configuration review.
- Partial downstream failure: Preserve the successful enrolment and create separate service-retry tasks.
Use case 4: Complete university enrolment
As a Student Section Officer
I want to submit and track university enrolment
So that the admitted learner receives the required university registration.
Acceptance criteria
- The officer prepares the university-required data from the approved admission and student record.
- Submission status is tracked as Not Submitted, Submitted, Returned, Accepted, or Enrolled.
- University deficiencies are linked to the responsible institutional owner.
- The university enrolment number and acceptance evidence are retained.
- A returned submission does not cancel the institutional admission automatically.
Negative cases and alternate flows
- University rejects data: Record the reason and correction workflow.
- Submission deadline approaching: Create an escalation alert.
- Admission later cancelled: Start the university-withdrawal process while retaining the enrolment history.
Success outcome
The joined candidate becomes one correctly identified student with one correct programme enrolment, and every downstream module can trace that enrolment back to the admission evidence.