Your school's data, in a form you can actually take with you
The question worth asking any school software vendor is not what happens while you are a customer. It is what happens if you stop being one. A system that is easy to put data into and hard to get data out of has made a decision about who the data belongs to.
SkoolBook answers that with an export you can run yourself, from a screen in the portal, without asking us: every table your school holds, written as both CSV and JSON, with a manifest, a SHA-256 for every file and a README explaining the layout. It is on every plan — including the entry-level one — because we do not think portability is something to sell you back.
What you get
Everything, in two formats, with checksums
Each table is written as CSV for a spreadsheet and JSON for a program, alongside a manifest and a SHA-256 per file so the recipient can prove the archive is intact and unaltered.
Protected fields come out readable
Sensitive fields are stored encrypted and are decrypted on the way out, because an export of ciphertext is portable in name only. Anything that cannot be decrypted is included as its raw stored value with a note rather than silently blanked.
One child's record, for the family that asks
A student-scoped export produces that one child's record across every module — the portable form a family may ask for under the Digital Personal Data Protection Act. A campus-scoped and a whole-school export are the other two options.
Built when you ask, stored nowhere
The archive is assembled at the moment you download it and kept in no bucket afterwards, so a file containing every child's name, date of birth, address and national ID is not sitting somewhere waiting to be found. What is retained is the audit record of who exported what, and when.
New modules are included the day they exist
The export reads the list of tables from the database itself rather than a hand-maintained list, so a module added next year is in your export without anyone remembering to add it. A list that has to be updated is a list that will one day be wrong.
How it works
- 1
Choose what to export
The whole school, one campus, or one student — from the export screen in the portal.
- 2
The request is recorded
Who asked, in what role, for what scope. That row is the audit trail and it exists whether or not anyone downloads the archive.
- 3
Download the archive
The files are assembled on the spot and streamed to you as a ZIP, with the checksum published in the response so you can verify it.
- 4
Verify and keep it
Check the SHA-256 against the manifest. The archive is yours; nothing about it stays behind on our side.
Frequently asked
Is data export an extra?
No. It is included on every plan, including the entry-level one. A school's own records are not a feature we think should sit behind an upgrade, and pricing it that way would make leaving expensive on purpose.
How long does an export take?
A whole school of a typical size completes in about a second — a verified full run covering 62 tables and 587 rows produced a 97 KB archive in under one. There is a size ceiling, and an export that would exceed it fails and tells you the size rather than quietly handing you a truncated file.
Who is allowed to export?
The principal, the trust administrator and the managing director. It is enforced by the database as well as the application, and what any of them receives is still limited to what their own role may read — a principal's export is scoped to their campus.
Can we schedule an export to arrive automatically?
Not today. Exports are run on request from the portal, and there is no automated delivery to an inbox or a storage bucket. We would rather say so than have you plan around something that does not exist.
What about a parent asking for their child's data?
That is the student-scoped export: one child's record across every module, in a portable form, which is what the Digital Personal Data Protection Act entitles them to ask for.