Admissions
Admissions pipeline
The full path from a public application to a student on the roster, and — the part a migration actually needs — exactly what data crosses each boundary and what has to be re-entered.
Admissions guide for day and boarding schools.
Last updated August 29, 2026
Admissions runs on cycles, each tied to one academic year, with its own application window, form configuration, optional application fee, and optional test and interview stages. Staff move applications through the pipeline until an accepted offer is enrolled, at which point a student appears on the roster and the admissions record stops being the source of truth. The interesting part of this module is not the stage list — it is the handover at the end, because that is where a school discovers what it has to re-enter.
Pipeline stages
Public vs staff surfaces
| Audience | URL | Purpose |
|---|---|---|
| Applicants / parents | /admissions/apply | Submit application and documents |
| Applicants / parents | /admissions/track | Check status with application ID |
| Admissions staff | /admissions | Dashboard, funnel, and cycle health |
| Admissions staff | /admissions/applications | Review, verify documents, change status |
| Admissions staff | /admissions/intake-plan | Seats vs applications and capacity targets |
| Admissions staff | /admissions/offers | Issue and track offer letters |
| Admissions staff | /admissions/enrollments | Convert accepted offers to students |
What crosses each boundary
| Boundary | What carries across | What does not |
|---|---|---|
| Application to student record | First name, last name, gender, the offered grade and stream, a generated registration number and roll number, and a class membership for the cycle academic year. | Date of birth, blood group, Aadhaar number, address, previous school, and admission category. They remain on the application only. |
| Application to guardian record | Guardian name, relationship, phone, email, occupation, and the full postal address, saved as the primary guardian for that student. | Nothing is created for a second guardian, and the father and mother name fields on the application are not turned into records. |
| Guardian record to parent portal | A portal login and a welcome sign-in link, when the guardian email is not already used by another account. | A login for a sibling’s guardian on the same email. That guardian is saved without portal access and has to be handled by hand. |
| Student record to fees | Fee instances for the cycle academic year, generated from whichever fee structures already exist for that year and class. | Anything at all when no fee structure exists yet — enrolment completes silently without fee lines, and you generate them later. |
Two details are worth stating plainly because they cause support tickets. The student account never uses the guardian email: it takes the student email from the application if one was given, and otherwise a synthetic address built from the registration number, which cannot receive mail. And the family is only notified about the new fee lines when a portal login was actually created, so a guardian who missed out on a login also misses the fee notification.
Common questions
Quick answers in plain language.
What data from the application actually reaches the student record?+
First name, last name and gender, plus the class the offer named. Date of birth, blood group, Aadhaar number, home address, previous school and admission category stay on the application, because the user table has no fields for them. The guardian fares better: name, relationship, phone, email, occupation and the full address are copied onto the guardian record. If your roster needs a date of birth, plan for that gap before go-live.
Who is allowed to enrol an accepted offer?+
Only an admissions in-charge: Platform Admin, Principal, Vice Principal, or the chair of the Admissions committee. Other committee members can read the pipeline and review applications but get a refusal on enrolment, on issuing offers, and on scheduling tests and interviews.
Do unaccepted offers expire on their own?+
Only if the daily cron is scheduled. Expiry runs from scripts/run-school-cron.sh with ADMISSIONS_CRON_SECRET set; without it, an offer past its deadline stays pending, keeps counting against the seat maths, and never frees the place. Waitlist auto-promotion needs the additional ADMISSIONS_AUTO_PROMOTE_WAITLIST flag on top of that.
Related searches
School leaders and IT teams often search for: admission management workflow, and apply to enroll system.