Skip to main content
Documentation

THE MANUAL,
WRITTEN BY THE PEOPLE
WHO DO THE SETUP.

This is the reference we work from during onboarding. It is deliberately practical: checklists, file formats, and the decisions you have to make before the software can help you.

Before you start

Five decisions have to be made by the school, not by us, and every one of them blocks something downstream. Settle these first and the rest of setup is mechanical.

DecisionWho owns itBlocks
Which academic years migrate as live recordsSchool ownerImport, archive
The identity key for reconciliationRegistrarAll user creation
Period structure and day patternsDeputy headTimetable, attendance
Charge types, discounts and installment calendarFinanceInvoicing
Grading components and weights per courseHeads of departmentGrades, report cards

Our recommendation on the first row is consistent: migrate the current and previous academic year as live records, and archive everything older as documents. Historical data nobody queries still has to be cleaned, mapped and supported forever.

Academic year setup

The academic year and its terms are configured once and referenced everywhere — attendance rollups, grade windows and fee schedules all key off them. Define:

  • The year label as families recognise it, e.g. 2026 / 2027
  • Term boundaries as actual dates, including the last teaching day rather than the last calendar day
  • Non-teaching days: public holidays, exam weeks, and any shortened-day patterns

Shortened days are a day-pattern change, not a timetable change. If you find yourself editing individual lessons to handle Ramadan hours, stop — that is a signal the day pattern has not been configured.

Import file formats

Imports run through Feeds with a dry run first. Each role has its own file. Column order does not matter; column names do.

students.csv

ColumnRequiredNotes
student_idYesYour identity key. Must be unique and stable across years.
first_name_en, last_name_enYesAs they should appear in English interfaces and documents.
first_name_ar, last_name_arRecommendedFalls back to the English name if omitted.
date_of_birthYesISO format, YYYY-MM-DD.
class_groupYesMust match a class group that already exists.
guardian_1_id, guardian_2_idAt least oneIdentity keys from guardians.csv.
enrolment_dateNoDefaults to the start of the current academic year.

guardians.csv

One row per person, not per child. This is the single most common import mistake: a parent with three children in the school appears three times, and you end up with three accounts that each see one child.

ColumnRequiredNotes
guardian_idYesIdentity key. Reconciled before anything is created.
full_name_enYes
emailRecommendedUsed for the account invitation. Rows without it produce printable credentials instead.
mobileRecommendedInternational format including country code.
preferred_languageNoen or ar. Defaults to the school setting; each guardian can change it later.

Teachers and drivers follow the same shape with teacher_id and driver_id as their keys. A dry run reports matched rows, new records and anything ambiguous — review that queue before committing.

Building the timetable

Order matters here:

  1. Define periods (named, e.g. P1–P7) and the clock times per day pattern.
  2. Create class groups and confirm their rosters are correct after import.
  3. Create courses and assign teachers.
  4. Place courses into timeslots per class group, with rooms.
  5. Export the PDF and physically walk it against room allocation.

Step five is not optional in our process. Every school we have onboarded has found errors this way, and every one of those errors would otherwise have surfaced as a support ticket in week two.

Fee structure

Configure in this order: charge types → discount types → tuition records → installment schedule → invoices. Trying to raise invoices before the discount rules exist produces manual adjustments that nobody can explain three months later.

  • Charge types are what a school bills for: tuition, registration, transport, uniform, exam fees, trips.
  • Discount types carry their own rule — percentage or fixed, and what they apply to.
  • Tuition records tie a plan to a student for a specific academic year.
  • Installments should follow term boundaries, not fiscal quarters.

Roles & permissions

RoleSeesCan change
Site administratorEverything, including configurationEverything
School managerAll students, staff, finance and reportsAcademic settings, staff, fee configuration
RegistrarStudents, guardians, class allocationEnrolment records, guardian links
Finance officerInvoices, payments, balancesCharges, discounts, payments
TeacherTheir own courses and studentsLessons, homework, quizzes, attendance, grades for their courses
StudentTheir own recordHomework submissions, quiz attempts
ParentTheir linked children onlyTheir own profile and language
Bus driverTheir assigned route and ridersNothing academic

Roles are additive: a teacher who is also a parent holds both, and each context shows only what that role permits.

Rolling out to parents

Stage it across at least three days, in this order: office staff, then teachers, then parents by year group. Do not activate parent accounts the night before term — we have made that mistake and the school's front office paid for it.

Before the first invitation goes out, send families a short message explaining what the portal is, what they will be able to see, and where to get help. The reset-request volume in the first 48 hours is roughly proportional to how well that message was written.

Termly tasks

  • Before term: confirm term dates, freeze grading formulas, generate the installment schedule, publish the fee calendar to families.
  • Week one: verify class rosters against actual attendance, check the timetable against reality, confirm every teacher can log in.
  • Mid-term: review attendance rollups for anomalies — a class with zero recorded absence is a data problem, not a discipline success.
  • End of term: close the grade window, run the collection report, archive completed courses.

Something missing or wrong here? This page is maintained by the implementation team and updated whenever an onboarding turns up a gap. Tell us what you were looking for and we will add it. Report a documentation gap or browse the help centre for task-level answers.