All modules Admissions & Students

Student Admission software for Indian schools

Digital enrollment workflow

Feature identity
Student Admission
An illustration, not a screenshot. The interactive example below shows what this capability actually does.

Student Admission in a school workflow

Admissions & Students

01
Required context
Configured classes/sections and admission-number settings must be confirmed before rollout.
02
Supported work
Server-minted sequential admission numbers shared by every create path — manual, import, convert, transfer.
03
Reviewable result
A validated student record with a server-issued admission number, guardian links and controlled class-section allocation.

Example record

Student Admission

Authorised view

Server-minted sequential admission numbers shared by every create path — manual, import, convert, transfer
Class-capacity caps with a least-filled-section allocation hint
Guardians captured for WhatsApp updates; a QR-verifiable ID card prints immediately
CSV bulk import with per-row validation preview — imported batches never message parents

Code-native illustrative example · not live product UI · no customer dataExample labels and outcomes come from this capability's reviewed catalogue record.

Product scope

What it does

Enrol a student in one form: the admission number is server-minted and sequential (ADM0001…), guardians are captured for WhatsApp updates, and a QR-verifiable ID card can be printed immediately. Class-capacity caps and a section-balance hint keep allocation sensible.

The school problem

School teams need a dependable way to handle Student Admission: Digital enrollment workflow. The required records, assigned roles and review boundary must remain explicit.

Day-to-day work

How your school uses it day to day

Digital enrollment workflow.

Server-minted sequential admission numbers shared by every create path — manual, import, convert, transfer
Class-capacity caps with a least-filled-section allocation hint
Guardians captured for WhatsApp updates; a QR-verifiable ID card prints immediately
CSV bulk import with per-row validation preview — imported batches never message parents

Operational result

What your school gets

A validated student record with a server-issued admission number, guardian links and controlled class-section allocation.

Access and ownership

Who typically uses it

Admissions officer
Front-office executive
School administrator
Principal

What each person can actually see depends on the role you give them and which classes or records you assign.

Availability and setup

What to confirm before rollout

Admissions & Students catalogue capability

Configured classes/sections and admission-number settings
Confirm plan scope, role permissions, data dependencies and any provider or migration prerequisites during the demo and proposal.

Flagship workflow deep dive

Student Records, Admission Numbers & Family Self-Service

One record per child. One numbering scheme. One audited trail.

Create and maintain the student register a school runs on: server-assigned admission numbers, capacity-aware section placement, guardian records, one-time credential handover, OTP-verified self-registration with a staff review queue, and family correction requests that change the record through an audited path instead of a phone call.

Interactive operating model

How a student record earns its number

Each stage shows what enters the record, which control gates it, and the evidence left behind.

Illustrative workflow · no customer data

Stage 1 of 5

Record enters

A manual add, an approved self-registration, a converted admissions lead or a reviewed import row.

Control point

Every path runs the same validation and the same server allocator — no side doors.

Evidence retained

Source stamp, created-by and creation time on the record.

Core workflows and features

The operational work behind the promise

Server-assigned admission numbersAdmission numbers come from one per-school sequential allocator — never typed by hand, never duplicated across two competing schemes.
Every create path shares the schemeManual add, approved self-registration, admissions-lead conversion and reviewed bulk import all mint from the same server allocator.
Capacity-aware section placementA configured class cap refuses over-admission with an explicit administrator override; a least-filled-section hint supports the decision.
Guardian records and sibling visibilityGuardians are recorded with the student, and siblings surface automatically from a shared guardian contact on the student's page.
One-time credential handoverAn admin-added student receives a registration number and a generated temporary password shown once — credentials never travel over SMS.
OTP-verified self-registrationA public wizard verifies the applicant's mobile by OTP before the submission lands in the school's review queue as a pending request.
Review, correction and approval queueAuthorised staff approve, reject or request a field-scoped correction; approval creates the student and assigns the numbers.
Family correction requestsStudents and parents request changes to whitelisted fields from their portal; the school approves and the record changes with an audit trail.
Printable ID cards with public verificationGenerate printable student ID cards whose QR resolves to a public verification page exposing only the printed fields.
Governed status changesStudent status moves through a governed state machine — a withdrawal can automatically issue the transfer certificate on the way out.
RTE and CWSN recordingRecord RTE admissions and CWSN support needs on the student record, with a dedicated report for the school's returns.

Migration Copilot import

Bring your existing register across — reviewed, never blind.

The Migration Copilot reads an uploaded student CSV or XLSX, proposes a column mapping and flags row-level validation issues. Staff review and correct the staged records before anything commits.

Propose a column mapping for the uploaded spreadsheet and flag per-row validation problems for review.
Stage the records so the school can correct rows before any of them become real students.
Commit the approved rows in one transaction with an audit trail, stamping each record as import-sourced.
Keep imported records under onboarding safeguards so a bulk import can never trigger reminder messages by itself.

Human boundary

The Copilot never admits a student on its own. A school administrator reviews the proposed mapping and the staged rows, and only their approval commits; admission numbers are always minted by the server allocator — never by the model.

Key daily uses

What the school team does here

Add a walk-in admission with the number, section and credentials issued in one pass.
Work the self-registration review queue and request corrections where details are incomplete.
Approve or reject family correction requests against the record's audit trail.
Print ID cards for a class and verify one from its QR code.
Run the RTE/CWSN report for the school's returns.

Used by

Admission manager
Front-office executive
Class teacher
Principal
Tenant administrator
Parent or student (self-service)

Actual access follows the school's plan, role permissions and record scope.

Measurable operating indicators

Metrics to track — not guaranteed ROI

Establish a baseline before rollout, agree the reporting period, then compare the school's own source evidence.

Record completeness

Active students with guardian contact, class-section and required documents on file ÷ active students

Shows where record follow-up is needed before report-card and returns season.

Activation coverage

Student and parent logins activated ÷ active students

The activation report breaks this down per class-section so the school knows who still needs a credential handover.

Correction turnaround

Correction requests resolved ÷ correction requests filed

Keeps the self-service loop honest — a stuck queue sends families back to phone calls.

Prerequisites and availability

Confirm the operating context before rollout.

Core student-record capability · self-registration and import paths are configured per school

Confirm class-section structure, capacity caps and the admission-number prefix before the first intake.
Self-registration requires the school's registration window to be open and a configured messaging path for OTP delivery.
The Migration Copilot import is included from the plan tier that carries migration; confirm inclusion in the live plan matrix.
The school verifies applicant data, documents, consent and its own admission policy before approving any record.

Connected operating context

Available workflows

These are the documented neighbouring capabilities that school teams may review with this module. A related page does not imply that every hand-off is automatic or enabled in every plan.

Explore all modules

Buyer questions

Frequently asked questions

The questions school owners ask before they subscribe: what it does, who can see it, and what to set up first.

Who assigns admission numbers?

The server does. Admission numbers come from one per-school sequential allocator used by every create path — manual add, approved self-registration, lead conversion and reviewed import — so a school never ends up with two competing numbering schemes.

Can families fix a wrong date of birth themselves?

They can request it. Students and parents file field-scoped correction requests from their portal; the school reviews and approves, and the record changes through an audited path rather than a phone call.

Does Student Admission work on its own?

Enquiry Management, Class Management, Section Management, Document Management are the documented neighbouring capabilities. They help a school evaluate the surrounding hand-offs, but a related page does not mean every integration is automatic or included in every plan.

What should our school prepare before enabling Student Admission?

Configured classes/sections and admission-number settings. Confirm plan scope, role permissions, data dependencies and any provider or migration prerequisites during the demo and proposal.

Is AI used in Student Admission?

No AI capability is asserted for Student Admission. Its documented work remains controlled by school records, roles and permissions.

How do we confirm the plan and implementation scope?

Plan inclusion and rollout scope depend on the live plan matrix, readiness state and your school's written proposal. The demo team will confirm the applicable boundary before rollout.

Related evaluation guides

See the Admissions & Students workspace Compare plans and commercial costs

See it in your school context

Run student admission the connected way.

See how this workflow fits your school's current records, roles, plan and rollout requirements.