Multi-school and campus switching

One deployment can hold several schools. Each gets its own record with its own name, branding, settings, careers pages, and public website, and the activity log records which school an action belonged to once more than one is active. That is the whole of what separation means here, and it is worth reading the next paragraph before planning a group rollout on this basis.

The academic and financial spine is not school-scoped. Class, AcademicYear, fee structures, payroll, and boarding records carry no schoolId at all, so two schools sharing a deployment share those tables. For a trust whose campuses genuinely run their own calendars and fee books, the honest recommendation today is a separate deployment per school; sharing one is appropriate where the schools are administratively a single institution on more than one site.

What holds true today

• A user record has one optional schoolId. There is no way for an account to belong to two schools.
• Only the Platform Admin role may switch. POST /api/schools/switch returns 403 for every other role, and switching changes that administrator own schoolId.
• Branding, school information, careers, and the /myschool website are per school.
• The activity log stores a schoolId and scopes entries once more than one school is active.
• While only one active school exists, users with no schoolId are treated as belonging to it. Add a second and that leniency stops, which is what surfaces unassigned accounts.

Limits to plan around

• No row-level separation of classes, academic years, fee structures, payroll, or boarding.
• No campus switcher for ordinary staff, and no group role that reads across schools.
• No consolidated reporting. Every report answers for one school.
• A screen that needs a school context will refuse rather than guess when several are active and the signed-in user has none.