TurtleDock
SchoolDeck · Feature

One student record, from admission to transfer certificate

A student information system holds the single authoritative record for each student — admission number, demographics, guardians, PEN and APAAR identifiers, section history, attendance, fee ledger and results. In SchoolDeck every other module reads and writes that one record rather than keeping its own copy.

It is the record, not the reporting. Board returns and analytics read from it, but the SIS itself does not file anything on your behalf.

Most school databases are corrupt by year four, and almost always for the same reason: a student who repeated a year, or transferred in mid-session, acquired a second record. From then on the fee ledger belongs to one identity and the attendance to another, and nobody notices until a transfer certificate has to be issued.

Identity
One admission number, carried for life of enrolment
Identifiers
PEN and APAAR stored on the record
History
Section, attendance, fees and results, year on year
Audit
Every change logged with user, time and prior value
01

What the record actually holds

  • Identity. Admission number, name as on the birth certificate, date of birth in figures and words, gender, category, mother tongue.
  • Statutory identifiers. PEN where the state has allotted one, APAAR ID, and the school’s UDISE code against the enrolment.
  • Guardians. Parents or guardians with contact details and the relationship, which decides who receives what.
  • Placement history. Class and section per academic year, promoted forward rather than re-created.
  • Ledger and outcomes. Fee ledger, attendance, assessment results, and documents issued.
02

Promotion, repetition and the duplicate-record problem

At year close, promotion moves the record forward. It does not copy it. A student who repeats Class 9 has one record with two years at Class 9, not two students who happen to share a name and a date of birth.

This is the single most consequential design decision in a school database, because a duplicate is cheap to create and enormously expensive to unwind. By the time it surfaces there are receipts on one identity, marks on the other, and a PEN allotted against whichever the office happened to use that day.

FAQ

Questions people ask

Phrased the way they arrive, answered so each one stands on its own.

What is a student information system?

A student information system is the authoritative record of each enrolled student — identity, guardians, statutory identifiers, placement history, attendance, fees and results. Other modules read from it rather than keeping separate copies, which is what stops the fee register and the class register diverging.

Can we import our existing student data?

Yes, from spreadsheets or another system. You are given validated templates and the files are checked before anything goes live. Duplicate detection runs on the import, because inherited duplicates are the most common thing a migration surfaces.

How are PEN and APAAR handled?

Both are stored on the student record and carried through promotion, so a student who moves up a class keeps the same identifiers. Where the state has not yet allotted a PEN the field stays empty rather than being filled with a placeholder.

Related

Read next

Provenance

Who checked this, and against what

Accountability

Checked by the Implementations desk on 1 September 2026. Corrections go in the page, dated, rather than quietly.

No call required

Tell us your enrolment, we will tell you the number.

Pricing is on the page, in the open, with the counting rule written next to it. Nobody has to book a call to find out what it costs.

See pricing

Bring your own structure. We configure it live on the call.

Forty minutes with an implementation engineer — your classes, your fee heads, your grading scheme, entered as we go. No slides, no sample school.