Timetable Management for Multi-Campus Groups, Built for Federated Operations

The architecture is federated by default, not centralised. Each campus owns its bell schedule, term calendar, room inventory, and local staff. The group office owns shared faculty contracts, common assessments, group-level reporting definitions, role policy, and master data governance (course codes, subject codes, programme codes). Configuration locks at the group level prevent a campus admin from drifting a shared field, but everything site-specific stays site-specific. AACRAO's guidance on multi-campus governance — that registrarial authority should sit closest to the student record while academic policy sits at the group level — is reflected in how permissions are scoped out of the box.

Visiting and peripatetic staff are group-level resources with a single contract record specifying total weekly hours, per-campus allocation, travel windows between sites, and rate. The scheduler treats each visit as a recurring multi-campus appointment: it books the teaching slot at the destination campus, blocks the travel buffer (parameterised by distance or scheduled mode of transport), and reserves the return slot if the teacher is going back. Contracted-hour caps are enforced across all campuses, not per site. Invoicing rolls up to a single statement against the group entity, with cost-centre breakdown for inter-campus chargeback if your finance model needs it.

Yes, and that is the whole point of being on one tenant rather than three. Group reporting normalises across campus-specific bell schedules: a 'period' at Campus A and a 'block' at Campus B are both converted to instructional minutes before comparison. Course catalogues map to a shared programme taxonomy at the group level. KPIs (fill rate, utilisation, attendance, pass rate, cost per contact hour) are defined once at the group office and computed identically everywhere. Exports feed your group BI layer via REST API, scheduled CSV, or warehouse connector. Per the EDUCAUSE 2024 Enterprise IT survey, multi-campus systems that rely on per-campus extracts and Excel reconciliation lose roughly 40% of analyst time to data preparation; a single-tenant deployment collapses that overhead.

OpenEduCat for multi-campus groups deploys as a single logical tenant with per-campus database partitioning and per-campus configuration scope. There is one application instance, one identity provider integration, one upgrade cycle, and one backup pipeline, but every campus has its own configuration profile, its own users, and its own data isolation. For groups that require physical data residency separation (a campus in the EU, another in Singapore, another in the US), the system supports regional instances bridged by a federation layer that synchronises shared resources (faculty pool, group reporting, common assessments) without replicating student PII across borders. The single-tenant default is faster to deploy and easier to govern; the federated regional model is for groups with hard data-localisation constraints.

Pricing is per active user (student plus staff) with group-tier volume bands rather than per-campus seat licensing, so a 5-campus group of 8,000 students is materially cheaper than five 1,600-student SaaS contracts. There is no per-instance setup fee for additional campuses after the first, because they are configuration not new deployments. Implementation is one project (data model, identity, master data) plus per-campus rollout waves rather than a fresh implementation per site. Total cost of ownership for groups we have benchmarked runs 45–60% below the equivalent of running per-campus Aeris or Infinite Campus instances when you include integration, BI, and reconciliation overhead.

Aeris and Infinite Campus are mature SIS products in the US K-12 district model, where a district licenses one product for many schools under uniform state reporting. They work well for that context. For multi-campus groups that are not a US public district — international K-12 chains, university systems with branch campuses, polytechnic networks, and holding-company education groups — the district model breaks down because the campuses don't share a single state's compliance regime, don't run identical calendars, and often span jurisdictions. OpenEduCat is built for that case: it does not assume a single state SIS export format, it does not assume identical term dates, and it federates configuration across heterogeneous sites. ISBA group-school operations guidance has been explicit that holding-group education operators need scheduling and SIS tooling designed for federation, not district-style uniformity, and that's the gap this addresses.