Organizations & Classes
Amal organizes a school network into three levels: the organization, the school, and the class. Every piece of data, from a student’s reading results to a teacher’s class assignments, belongs to one organization and cannot cross into another.
The three levels
Organization
An organization is the top-level tenant. It usually corresponds to a school network, a regional education authority, or a private school group. All schools, classes, users, and student data under an organization are isolated from every other organization. Two organizations can run on the same platform and neither can see anything that belongs to the other.
When a super-admin (a platform operator) accesses a resource that belongs to an organization other than their own, that access is recorded automatically in an audit log. This happens every time, not only when something unusual occurs.
Each organization is associated with a country, and schools created under it must match that country. This prevents an administrator from accidentally mixing curriculum content or benchmark standards across different national contexts.
School
A school sits inside an organization. It has a principal assigned to it (at most one at a time), and it contains one or more classes. When a school is deleted, the deletion is soft: the data remains but the school no longer appears in active lists. Hard deletion is not available because the historical reading records tied to that school need to stay intact.
A manager role can be scoped to a specific set of schools within an organization. A manager with an explicit school list sees only those schools in all views. A manager with no explicit restriction sees all schools in their organization.
Class
A class belongs to a school. It has a grade level, and every student enrolled in it is measured against the benchmarks for that grade. A class can have multiple teachers assigned to it, and a teacher can be assigned to multiple classes. Both of those are normal, not edge cases.
Classes are also soft-deleted when removed. Student data tied to a class stays available in the system even after the class is no longer active.
Keeping data separate between organizations
Every table in Amal’s database that stores runtime data carries the organization identifier. It is not just on the user account at the top; it is on the reading results, the progress records, the session logs, the support assignments, and every other row that belongs to a specific school context.
When a user makes a request, the server derives their organization from their verified identity and folds it into every database query. A row from a different organization simply does not match the query predicate, so it does not appear. The response is a 404 rather than an access-denied error, which avoids revealing whether a resource exists at all.
This is not optional or configurable. There is no mode where cross-organization data sharing is enabled. The isolation is structural.
The multi-class teacher rule
A teacher can teach more than one class. This is not a special case that requires extra configuration; it is the default expectation.
The link between a teacher and a class is recorded in a dedicated junction that stores both the class identifier and the teacher identifier together. Every authorization check that involves a teacher and a class reads from that junction. There is no shortcut field on the class itself that points to a single teacher.
This matters for access control. When the server checks whether a teacher can view a student’s results or submit a plan, it looks up the junction to confirm the teacher is assigned to that specific class. Being at the same school is not enough. Being assigned to one class in a school does not grant access to another class in the same school.
A teacher who is assigned to three classes can act on all three. If they are removed from one, they lose access to that class immediately, even if they still have active sessions for the others.
The same teacher can hold different roles within different classes. In one class they may be the lead teacher; in another they may be a co-teacher. The junction records the role in each class separately.
How administrators manage the network
Creating a school network starts at the organization level and works downward. An administrator creates an organization, then creates schools within it, then creates classes within those schools. Users are created separately and then linked: a principal is assigned to a school, teachers are assigned to classes, students are enrolled in classes, and parents are linked to specific children.
The admin can view a rollup of any organization: how many schools it contains, how many classes each school has, and how many students are enrolled. This rollup is filtered by the requesting admin’s own scope.
Soft-delete operations are available at every level. Deleting an organization deletes it softly; deleting a school or class inside it does the same. A deleted organization does not appear in the global list but its data remains queryable for audit purposes by platform operators.
Where to go next
- Roles & Access covers what each role can do and how permissions are enforced.
- Provision Users walks the steps for setting up a network for the first time.
- Managers & Principals explains the school-leader views in more detail.