Student information system

The system of record for every student you're responsible for.

JEduManage's SIS holds each student's identity, enrollment, parent linkage, and full history. Every other module — attendance, fees, exams, parent portal — reads from it, which means student data has one source of truth across the school.

A student information system that doesn't double as the front door to the rest of the school's operations is the wrong tool. JEduManage puts the SIS at the centre and makes every other module hang off it: attendance, fees, exams, transport, and parent visibility all read from the same student record and the same enrollment row. There is no duplicate student in the fee module, no second copy in the attendance module, no third copy in the exams module.

What an SIS actually has to do

Stripped to essentials, a student information system owns four things: identity, enrollment, family, and history. Everything else a school product does — taking attendance, billing fees, generating report cards, sending an absentee SMS — reads from one of those four.

  • Identity — admission number, full name, gender, date of birth, photo, address. The admission number is immutable; everything else can change with audited update.
  • Enrollment — class, section, roll number, academic year. A student can have one current enrollment per year and a stack of historical ones from prior years.
  • Family — parent / guardian linkage, relation type (father / mother / guardian), primary flag for the school's preferred point of contact.
  • History — every transfer, promotion, withdrawal, re-admission. The history table is append-only and read by report cards, year-over-year analytics, and audits.

One admission number, one student, forever

A student keeps the same admission number from first admission to graduation. Their class, section, and roll number describe their current enrollment and roll over to a new row when the new academic year starts. Withdrawing a student soft-deletes the record so it stays available for archival reads (last year's report card has to render even if the student has left); re-admitting brings the same record back with new enrollment.

The practical effect is that "where is this child's record?" is never ambiguous. There's one row, one admission number, and one parent linkage — regardless of how many years they've been at the school or how many classes they've moved through.

Parents linked at admission, not later

When the admin admits a student, they enter the parent's phone number. If a sibling already studies at the school, the existing parent account is reused and the new student is linked to the same guardian — no duplicate parent records, and the parent's portal now lists both children. If the phone is new to the school, a fresh parent user is provisioned in the same database transaction as the student admission, and the credentials are messaged to the parent over SMS.

Linking parents at admission (not as a separate workflow afterwards) means the SMS pipeline knows immediately whom to message, the fee flow knows whose phone to send reminders to, and the parent portal works from the first login.

Transfer, promote, withdraw — three flows, one record

The SIS distinguishes three enrollment-changing actions: transfer (mid-year section or class change), promote (year-end advancement), and withdraw (departure). Each is a separate, audited workflow that updates the student's enrollment while keeping admission number, parent linkage, attendance history, and fee record intact.

The audit log records the actor, the timestamp, the previous values, and the new values for every transfer and promotion. A principal investigating a parent's complaint about which section a child was in last term can reconstruct the answer from the audit panel — no interview round required.

Bulk import for the first day of an academic year

The first time a school comes online (or the first day of every new year), there is a roster to load. JEduManage's bulk CSV import takes the standard fields and validates each row before any write happens. Errors come back as a per-row report; valid rows are imported atomically. There's no partial state where half the class made it in and the other half didn't.

How the SIS feeds every other module

The student record is the cornerstone. attendance management reads enrollment rows to populate the section roster. fee management reads the student's class and academic year to apply the right fee structure. The bus-route assignment hangs off the student's fee record. Exam grading sheets pull the section's enrolled students. The parent portal pulls each child the parent is linked to.

That's the design dividend: when a student is admitted, all of the downstream flows just work — there are no separate setup steps in attendance or fees or exams, because every module reads from the same SIS.

Photo, address, and the long tail of student metadata

Beyond the four cornerstones, every school carries a long tail of student metadata that matters at unpredictable moments: blood group for sports day, allergies for the canteen, emergency contact for the school nurse, address for the transfer certificate, religion and category for government reporting, Aadhaar where the school is mandated to capture it. The SIS holds these as optional fields on the student record, all tenant-scoped and audit-tracked. Schools turn on the fields they need and ignore the rest — there is no government-form-style page of mandatory entries to scroll past.

Student photographs upload directly to S3-compatible storage with per-tenant prefixes. The same image renders inside the attendance roster (so a substitute teacher can match faces to names), on the ID card export, on the parent portal, and on the admission slip. One upload, every downstream use.

Sibling and family-level views

A parent with three children at the school sees a single login and three children listed. Fee dashboards, attendance calendars, and report cards are switchable child-by-child from the same screen — there's no need to log in three times. On the admin side, the family relationship is queryable directly: pulling up a parent reveals every linked student, the class each is in, the fee status of each, and the SMS log of every message that has gone to that parent's phone across all the linked children. The office no longer has to cross-reference three roster cards to have one conversation with one parent.

Year-end promotion is one screen, not a fortnight

The single hardest week in many schools is the first week of the new academic year — rosters need rebuilding, fee structures need reassigning, the previous year's data needs archiving without deletion. JEduManage's promotion flow is a single screen per section: pick the current class, pick the target class, review the student list, hit promote. Every student gets a new enrollment row for the new year; the previous year's row stays intact for archival reads; the new year's fee structure applies automatically. Students who are repeating get a checkbox to exclude from promotion. The whole school can roll over in an afternoon instead of a fortnight of spreadsheet surgery.

Where to look next

The SIS is the foundation; the surrounding modules are where the school's day-to-day work happens. The school management software page covers how the SIS connects to the rest of the school operations, the school ERP page covers the architectural picture, and the features page lists everything in one place. When you're ready to see your school inside the product, let's talk.

FAQ

Common SIS questions

What is a student information system (SIS)?
A student information system is the system of record for every student a school is responsible for. It holds the student's identity (name, admission number, date of birth, gender), their academic enrollment (class, section, roll number, academic year), their parent linkage, and their history across years (transfers, promotions, withdrawals). Other modules — attendance, fees, exams, communications — read FROM the SIS. JEduManage's SIS is the foundation that the rest of the platform builds on.
How does JEduManage identify students?
Every student has an immutable admission number (set at admission time) which serves as their primary identity inside the school. Class, section, and roll number describe their CURRENT enrollment and change across years; the admission number stays. The system enforces uniqueness on admission numbers within a tenant and provides a clean transfer/promote flow that updates enrollment without orphaning the historical record.
How are parents linked to students?
At admission time, the parent's phone number is used to create or link to a parent user. If a sibling is already in the school, the existing parent record is reused and the new student is linked to the same guardian — no duplicate accounts. Each parent-student link records the relation (father, mother, guardian) and whether the parent is primary. Parents see only their own children in the parent portal; multiple children are listed together.
Can student data be imported in bulk?
Yes. The admin Students page provides a CSV bulk import that takes the standard fields (admission number, name, date of birth, gender, parent name and phone, class, section, roll number) and validates each row before any data is written. The import returns a per-row error report so you can fix the source CSV and retry — partial imports never leave the database in an inconsistent state.
What happens when a student is transferred or withdrawn?
Transfers within the academic year update the student's enrollment to the new class/section/roll while keeping admission number, parent linkage, attendance history, and fee record intact. Withdrawals are soft-deletes — the record stays for reporting and audit but is removed from active rosters. Re-admitting a previously withdrawn student is a single action; the prior history is preserved.
How is student promotion handled at year-end?
Promotion is a bulk action at the section level. The admin selects the next academic year's class and section, and every student currently enrolled gets a new enrollment row for the new year. Their previous-year enrollment stays intact for archival reads. Fee structures for the new academic year apply automatically. Students who are repeating a class are handled individually.
Is parent data treated with the same care as student data?
Yes. Parent records are first-class users with their own login, password, and audit trail. Tenant scoping applies to parents the same way it applies to staff — a parent at School A cannot resolve a record at School B. The same phone number can legitimately appear on a staff record at one school AND a parent record at another (or even the same school, for a teacher whose own child studies there); JEduManage's role-specific login routes the phone to the parent record and the email to the staff record so portal identity never collides.

Move every school operation onto one calm surface.

See JEduManage in your environment. We'll spin up a working tenant with your school's branding, classes, and a sample student cohort — usually within the same day you reach out.