One record, admission to alumni
The admission form, the documents, the roll numbers, the ID card and the transfer certificate all hang off a single student record — and the student signs into a portal that reads the same one.
The admission register and its six copies
A student’s details are normally entered at admission, then re-entered into the fee sheet, the exam sheet, the transport list and the ID-card file. Every copy drifts. Here the record is entered once and every other module points at it, so correcting a phone number corrects it everywhere it is printed.
A bound admission register
A class-wise student list in Excel
A separate contact sheet for guardians
ID card data typed into a designer’s template
Students, screen by screen
Each of these is a screen or a service in the module rather than a heading on a roadmap.
Admission, with the slip at the end
A structured admission form covering the student, the guardians, previous school, category and documents, ending in an admission slip you can hand over or print rather than a database row you have to describe.
Roll numbers as a managed sequence
Numbers are allocated from a sequence per class and section rather than typed, so two students cannot end up sharing one, and re-numbering a class after admissions close is one operation.
Bulk import that survives your spreadsheet
An Excel file is read with alias matching on the column headings, so “Student Name”, “Name of Student” and “student_name” all land in the same field. Rows are validated and previewed before anything is written.
Bulk promotion and status changes
Promote, retain or graduate a whole class between sessions, or change status in bulk. Each change is written with the person who made it on the record, not as an anonymous update.
The documents a school has to produce
ID cards from templates that pull the photo and details off the record, and a transfer certificate generated from it — instead of a Word file somebody keeps in a folder.
A portal the student signs into
Their own timetable, notices, calendar, assignments, attendance and fee position, reading the same records staff are editing. A login resolves to exactly one student record and refuses to guess when the underlying data is ambiguous.
The same row, read from somewhere else
The point of an ERP is not that it has a lot of modules. It is that a fee concession, an attendance shortfall and a report card are all reading one record. These are the places Students touches.
Fees
Fee demands are raised against the student record and its class, so a concession, a sibling link and a defaulter list all read the same roll.
Notices
A notice audience is a query over classes, sections and named students — never a separately maintained mailing list.
Academics
Classes, sections, streams and houses come from Academics; the student record references them rather than storing its own copy of a class name.
What Students does not do
Stated here rather than discovered in week three. If something you need is on this list, ask before you buy — it is a better conversation than the one after.
The portal is for students. There is no parent portal in this build — guardian details are held on the student record and used for printed letters and phone calls, not for a login.
An Aadhaar number can be verified through a commercial verification provider you configure with your own credentials. It is a third-party API call, not a UIDAI or DigiLocker integration; the number is passed to the provider and not stored here; and with no provider configured the screen says so rather than pretending. Nothing about it is required to admit a student.
Bulk import writes students. It does not create their fee demands, transport allocations or hostel beds — those are deliberate steps in their own modules.
There is no mobile app. The portal is a website, which works on a phone browser but sends no push notifications.
Set your institution up on Elevate
Start on the free plan for up to 250 students. Paid plans begin at ₹1499 per month, billed to the institution.