Student Enrolment Handoff
Epic summary
The Student Enrolment Handoff epic is the controlled boundary between Admissions and the learner’s ongoing academic record.
Admissions prepares and tracks the handoff. Student and Cohort Management creates or links the person and student, uses the inherited institute programme, cohort, speciality, and curriculum version, issues the student number, and starts the university-registration process. Admissions retains the historical intake evidence; Student and Cohort Management owns the resulting student records.
The receiving workflow is documented in Student Record and Programme Enrolment.
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, institute, cycle programme, allotment, quota, decision, and joining event |
| Required completion | Admission approved, joined, no blocking movement, finance/bond condition satisfied, and documents complete |
| Academic assignment | Cohort, institute programme, speciality, curriculum 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 | Generated from the cohort’s pinned policy or validated under its Controlled Manual Entry policy |
| 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 |
|---|---|---|---|
| Institute programme | Inherited | Yes | Final admitted programme; cannot be changed during handoff |
| Planned cohort | Inherited | Yes | Cohort selected by the admission cycle programme; cannot be reselected during ordinary handoff |
| Curriculum version | Inherited | Yes | Published institute curriculum version pinned from the cycle programme |
| 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 |
University-registration fields
| Field | Entry type | Meaning |
|---|---|---|
| Affiliating/examining university | Inherited | Relationship configured for the institute programme |
| 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 institute programme, cohort, speciality, and curriculum-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 curriculum version: Return the case to Setup 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: Complete student enrolment
As a Student Section Officer
I want to complete one enrolment action
So that academic modules receive the correct student, programme, cohort, curriculum, and identifier context.
Acceptance criteria
- Institute programme, speciality, planned cohort, curriculum version, and student-number policy are inherited and read-only.
- One programme enrolment and one cohort membership are created together.
- A unique institutional student identifier is issued from the cohort’s pinned 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 setup 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.
Technical design
Conceptual schema
| Record | Important fields |
|---|---|
admission.enrolment_handoff | case, planned cohort, target programme/curriculum, readiness version, state, attempt key, errors |
people.person_match_review | candidate person, possible person, match evidence, reviewer, decision |
student.student_profile | person, institute, status, source admission case |
student.programme_enrolment | student, institute programme, curriculum version, admission case, start date, status |
student.cohort_membership | student enrolment, planned cohort, joined at, membership status |
student.student_identifier | student, programme enrolment, identifier type, value, issuer, pinned policy version, status, issued at |
student.university_registration | enrolment, university relationship, submission state, university number, evidence |
The student, programme-enrolment, and cohort-membership records are owned by Student and Cohort Management. Admissions owns the handoff request and its trace back to the admission case.
Process-layer responsibilities
- Recheck approved admission, joining, movement, and handoff readiness at submission time.
- Use a match review before creating a new person when a possible identity already exists.
- Create or connect the student, programme enrolment, membership, and student number in one retry-safe workflow using the pre-selected cohort and its pinned policy.
- Prevent two active enrolments from the same admission case.
- Preserve handoff errors and support safe retry without duplicating downstream records.
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.