One profile, a real lifecycle
Active, pending activation, fee pending, or inactive: a status that means the same thing on every screen.
03 · One record, their whole journey.
Records and transfers stay connected throughout every student's school journey.
Hear it from Syfty

Why it matters
A student's record shouldn't reset every time something changes about them. Edsyft gives each student one profile that carries a lifecycle status, active, pending activation, fee pending, or inactive, rather than a scatter of flags that different screens interpret differently. Every meaningful change to that record, a class change, a transport or hostel change, a document update, a lifecycle change, lands as a timestamped event on the student's own timeline, attributed to who made it and from which role.
Because a student belongs to the organization rather than to a single campus's database, moving between your own schools is a transfer, not a fresh admission. The transfer flow runs as a guided sequence: search for the student, choose the destination campus, review a readiness check, confirm, and see the result, and that readiness check is deliberately unforgiving: it verifies the two schools share an organization, confirms the student isn't already mid-transfer, checks the destination academic year is open and the class is mapped, and surfaces each side's fee position before anyone commits to the move.
Promotion at year-end works the same way: preview first, decide second, apply third. Org leadership reviews a proposed rollover: promote, repeat, hold, mark complete, or leave, for every student across every campus, with the system itself flagging rows that need a decision before they can proceed, like a student whose current class isn't offered at the target grade. Nothing promotes silently in the background.
When a student genuinely leaves, that's a recorded exit, not a row someone deletes. The office previews the effect first: fee position, guardian portal access, and related records. The exit is applied only after that preview is clear. The reason for leaving is captured on the record, so the story of why a student left doesn't have to be reconstructed from memory a year later.
What it handles
Every capability below maps to a real operating decision, handoff, or record inside the module.
Active, pending activation, fee pending, or inactive: a status that means the same thing on every screen.
Class changes, transport or hostel updates, document updates, and lifecycle changes stay on one timeline in order.
A guided search-to-confirm flow, with a readiness check that catches mismatched years and unmapped classes before the move happens.
Father, mother, or guardian contact channels are tracked with a clear source, so the portal invite goes to the right phone or inbox.
Promote, repeat, hold, or mark complete, reviewed for every student across the network before anything is applied.
Leaving is a recorded step with a reason on file, checked against fee position and portal access before it goes through.
How it is controlled
Permissions, approvals, and state changes are part of the workflow itself, not instructions left for a staff meeting.
The readiness check blocks the move outright if the destination year isn't open yet or the student's class has no mapping at the new campus.
A student whose class doesn't exist at the target grade is flagged for a decision. The system won't silently promote them into nothing.
Value propositions
What changes for the team once this module is running in daily work.
A student belongs to the organization, so a move between your own campuses is a transfer, not a re-admission.
A new office hire can see exactly how a record got to where it is, without asking around.