Help & User Manual
Complete user manual and new school onboarding guide. New schools should read sections 1–4 first and then follow the three-day onboarding checklist. Individual users can jump straight to their module.
1.Welcome to Smart School App
Smart School App by Raei Tech is a cloud-based School ERP for Indian schools. It connects student information, academics, attendance, examinations, fees, library, transport, communication and reporting.
Each school should maintain one authoritative student record, while role-based permissions control who can see and change what.
2.Getting Started
Register or receive your school account, verify the registered email, sign in, and complete the school profile.
Use strong unique passwords and never share administrator credentials.
- School name, logo and contact details
- Academic year, classes and sections
- Subjects, staff and roles
- Fee structure and examination settings
- Attendance, library and transport configuration
4.Users, Roles & Permissions
School Admin manages school-level users, roles, permissions and invitations. Assign the minimum necessary access.
For school chains, a Group Owner can have one login linked to multiple schools through explicit memberships and a school switcher. Parents are restricted to their linked student records only.
5.Student Information & Admissions
Admissions can begin with a parent enquiry, followed by follow-up and conversion. Register the student once and reuse the central student record across attendance, fees, transport, library, examinations and reports.
Assign class and section through authorized users. Bulk uploads validate mandatory fields and duplicates.
| Typical users | Use role-specific permissions configured by the school. |
|---|---|
| Data principle | Use central master records; avoid duplicate student/staff records. |
| Access principle | Only authorized users should view or modify data. |
| Common check | Confirm school, academic year and class/section context before saving. |
6.Academic Setup, Timetable & Diary
Configure academic year, classes, sections and subjects before creating timetables or examinations.
Class Teachers normally manage or view only their assigned class and section unless broader permission is explicitly granted. Diary and Academic Calendar support school and class academic events.
| Typical users | Use role-specific permissions configured by the school. |
|---|---|
| Data principle | Use central master records; avoid duplicate student/staff records. |
| Access principle | Only authorized users should view or modify data. |
| Common check | Confirm school, academic year and class/section context before saving. |
7.Attendance Management
Attendance uses statuses that are clearly distinct from examination marks: Present, Absent, Excused and Half Day.
Class Teachers access only their assigned class and section. Reports show each student's days present against applicable days rather than an all-student aggregate. Entry/exit time and monthly trends are supported where enabled.
| Typical users | Use role-specific permissions configured by the school. |
|---|---|
| Data principle | Use central master records; avoid duplicate student/staff records. |
| Access principle | Only authorized users should view or modify data. |
| Common check | Confirm school, academic year and class/section context before saving. |
8.Examination, Marks & Results
Authorized users create examinations and configure subjects, maximum marks, passing marks, dates and Internal Assessment. The default passing rule is 33% of maximum marks.
Field-level validation prevents obtained marks exceeding maximum marks. Auto-save, corrections before finalization, subject or all-subject CSV upload, and completion checks before final submission are supported.
Non-scholastic subjects show grades separately and are excluded from totals, percentages, rankings and pass/fail calculations. Absence is calculated as zero for the affected result and displayed as AB in remarks. Published exams are protected from inappropriate date changes.
| Typical users | Use role-specific permissions configured by the school. |
|---|---|
| Data principle | Use central master records; avoid duplicate student/staff records. |
| Access principle | Only authorized users should view or modify data. |
| Common check | Confirm school, academic year and class/section context before saving. |
9.Fee Management
Configure school-specific fees with one-time, quarterly and monthly installments where enabled. Authorized administrative and accounts staff collect fees, and all collections use Fee Receipt terminology.
Outstanding (due but not necessarily past the due date) is clearly distinguished from Overdue (past the due date). Transport fees integrate with the central fee system using stable category identifiers. Parents view only their own student's fee information.
| Typical users | Use role-specific permissions configured by the school. |
|---|---|
| Data principle | Use central master records; avoid duplicate student/staff records. |
| Access principle | Only authorized users should view or modify data. |
| Common check | Confirm school, academic year and class/section context before saving. |
10.Finance & Payroll
Finance supports income, expenses, receipts, payments, journals, bank reconciliation, assets, budgets and financial reports.
Payroll uses existing staff records rather than duplicate employees and can include salary components, deductions, PF, ESI, professional tax, TDS, loans, advances, bonuses and arrears as configured. Salary and bank data require restricted access and audit trails.
| Typical users | Use role-specific permissions configured by the school. |
|---|---|
| Data principle | Use central master records; avoid duplicate student/staff records. |
| Access principle | Only authorized users should view or modify data. |
| Common check | Confirm school, academic year and class/section context before saving. |
11.Library Management
Maintain catalogue, accession numbers, authors, publishers, subjects/categories, copies, locations and members.
Librarians issue and return books, manage reservations if enabled, calculate fines, maintain the online accession register and generate circulation and inventory reports. Library members reference central student and staff identities rather than duplicate people.
| Typical users | Use role-specific permissions configured by the school. |
|---|---|
| Data principle | Use central master records; avoid duplicate student/staff records. |
| Access principle | Only authorized users should view or modify data. |
| Common check | Confirm school, academic year and class/section context before saving. |
12.Transport Management
Configure vehicles, drivers, routes, stops and capacity, then allocate students using existing student records.
Allocation updates route, stop, vehicle occupancy and reports. Transport fees integrate with Fee Management so collection, outstanding and overdue values use authoritative payment records.
| Typical users | Use role-specific permissions configured by the school. |
|---|---|
| Data principle | Use central master records; avoid duplicate student/staff records. |
| Access principle | Only authorized users should view or modify data. |
| Common check | Confirm school, academic year and class/section context before saving. |
13.Announcements & Communication
Authorized staff publish notices, circulars and announcements to defined audiences. Class Teachers may communicate with their assigned class where permitted.
Audience, publication status and audit trail are recorded. Use supported in-app and email notification workflows; reminder delivery depends on a configured delivery service.
| Typical users | Use role-specific permissions configured by the school. |
|---|---|
| Data principle | Use central master records; avoid duplicate student/staff records. |
| Access principle | Only authorized users should view or modify data. |
| Common check | Confirm school, academic year and class/section context before saving. |
14.Certificates
Authorized users generate Study Certificates and Transfer Certificates using approved school templates and applicable board requirements.
Verify student identity, admission details, class and dates before issuing. Issued certificates remain auditable and protected from unauthorized alteration.
| Typical users | Use role-specific permissions configured by the school. |
|---|---|
| Data principle | Use central master records; avoid duplicate student/staff records. |
| Access principle | Only authorized users should view or modify data. |
| Common check | Confirm school, academic year and class/section context before saving. |
15.Reports & Analytics
Reports are role-specific and use authoritative module data. Teachers get attendance plus academic performance reports, including term-wise and consolidated full academic-year analysis where configured.
Progress Reports support term-wise printing. Fee, transport, library, attendance and examination reports provide filters, totals and export or print options.
| Typical users | Use role-specific permissions configured by the school. |
|---|---|
| Data principle | Use central master records; avoid duplicate student/staff records. |
| Access principle | Only authorized users should view or modify data. |
| Common check | Confirm school, academic year and class/section context before saving. |
16.Parent Portal
Parents sign in with school-issued credentials, and the parent name displays on the portal.
Depending on school configuration, parents view permitted student information, attendance, fees, results, announcements and transport. All queries are scoped to the authenticated parent's linked students; another student's information is never exposed.
| Typical users | Use role-specific permissions configured by the school. |
|---|---|
| Data principle | Use central master records; avoid duplicate student/staff records. |
| Access principle | Only authorized users should view or modify data. |
| Common check | Confirm school, academic year and class/section context before saving. |
17.Security, Privacy & Audit
The platform enforces tenant isolation, role-based access, strong authentication, secure password storage, encrypted transport and suitable encryption for sensitive data.
Recommended production controls include MFA for privileged administrators, rate limiting, CAPTCHA after repeated failures, temporary lockout, audit logs, encrypted backups, security headers, monitoring and vulnerability scanning.
Browser restrictions such as disabling right-click cannot prevent screenshots; real protection comes from authorization, encryption and secure architecture.
18.School-Chain / Group Management
Use Organization / School Group → Schools → Users & Memberships. One user can access multiple schools through explicit memberships.
A school switcher changes the active school context, while group dashboards provide consolidated information. Email alone is never used as an authorization key; stable user IDs, memberships, roles and permissions are.
19.Troubleshooting
- Login or verification issues: confirm the email, check spam, use password reset, and contact the School Admin if the account is not provisioned.
- Missing student: verify the central student record, school, academic year, class/section and status.
- Missing transport allocation: verify an active allocation and correct student, route, vehicle and school references.
- Transport fee missing: verify the correct transport fee category and payment status.
- Marks unavailable: check exam status and permissions.
- Announcement not posting: check required fields, audience and authorization.
- Parent invitation not received: verify recipient email, invitation status and configured mail delivery.
20.New School 3-Day Onboarding Checklist
- Day 1 — Activate the school, verify email, configure branding, academic year, classes, sections, subjects, staff and students.
- Day 2 — Configure attendance, timetable, diary/calendar, fees, examinations, library, transport, roles and parent invitations.
- Day 3 — Test teacher, accountant, librarian, transport and parent accounts; create a sample fee receipt; test attendance and marks; issue and return a sample library book; allocate a sample transport student; run reports; verify mobile layouts; complete UAT.
21.Go-Live Checklist
Confirm school profile and branding, academic year, classes and sections, subjects, staff, students, parent links, roles, fee structures, examinations, attendance, timetable, library, transport, announcements, reports, backups, security settings, email delivery and support contacts.
Run one end-to-end workflow before production use.
22.Frequently Asked Questions
- Can schools have different fee structures? Yes — fee structures are school-specific.
- Can a parent see another student's result? No.
- Can a Class Teacher see another section? Not unless explicitly authorized.
- Can one owner manage multiple schools with one email? Yes, through group/membership architecture and a school switcher.
- Should dashboards maintain separate duplicate data? No — they calculate from authoritative module records.
23.Support & Escalation
For school-level issues, contact your School Admin first.
For application defects, record school, role, module, steps, expected result, actual result, date and time, and the error message or screenshot. Never send passwords or unnecessary confidential student data through support channels.
Need more help?
Contact your School Admin first. For application defects, write to our support team with the school, role, module and steps to reproduce.