Multi-campus federation.

Every row in YESS already carries a school_id — that is how one school is walled off from the next. Multi-campus adds a second dimension inside a school: a campus_id on the operational tables, so the same tenant can be sliced by site. A campus manager in town B should not see town A's attendance, town A's invoices, or town A's staff. But the owner — sitting above both — should see everything, side by side.

That is the whole design problem, and YESS solves it with two ideas that recur on every screen in this book. First, a campus-scoped role: a grant that makes someone powerful on one campus and an ordinary member everywhere else. Second, a two-tier permission gate that checks both the school-wide permission and the campus grant before any action lands. Get those two right and federation is just bookkeeping.

A single school, federated — each campus run on its own, the whole one number the owner can read.

Greenwood runs two sites — the Main Campus in the city and the Annex ten kilometres out. Follow one morning and the rest of the book is detail.

07:50. The Annex principal logs in. Her topbar carries a campus switcher; it is already pinned to Annex. Every list she opens — attendance, invoices, staff — is filtered to her site. She could flip to All accessible, but her grants only reach the Annex, so the school-wide totals stay closed to her. The choice is remembered on her device.

08:05. A teacher who normally works the Main Campus is covering a class at the Annex today. The Annex principal opens /dashboard/attendance/campus-presence and there he is — the presence roster is built from the timetable, so it lists everyone teaching on this campus today, visitors included, not just the staff who are home-based here.

08:30. A family wants to move their daughter from the Annex to the Main Campus permanently. The registrar checks the rule: the school's mobility policy is Open, so a permanent transfer is allowed. The move is recorded; an append-only row lands in the student's campus history, and her campus_id follows her enrolment to the Main Campus automatically.

09:15. The proprietor opens /owner/campuses on his tablet. Two bars, ranked: enrolment, fee collection, and presence for the Main Campus against the Annex. The Annex is collecting at 81%, the Main at 68%. He forwards the screen to the Main bursar with one line.

A campus is a row in the campuses table, and it is the anchor everything else hangs from. You create and manage campuses at /dashboard/campuses — a roster with a KPI rail (campuses, students, staff, classes), a searchable table, a CSV export, and create/edit/delete dialogs gated by the campuses.create and campuses.edit permissions.

Each record carries an identity (name, address, phone, email), an assigned principal drawn from staff, a capacity, and — for schools that use it — a geofence: a GPS point with a radius, or a walked / drawn polygon, with the method chosen per campus (point-and-radius, polygon, or none). The geofence is what lets attendance and presence features know whether a phone is physically on this campus.

The most political question in a federation is who is allowed to move a student from one campus to another, and on what terms. YESS does not decide this for you — it gives you a policy you set. On a multi-campus school, the campuses page shows a mobility policy card (visible when you hold campuses.edit) with three settings:

Behind the card sits the campus_mobility_rules table. The policy you set on the page is the school-wide default — a single rule with no specific from/to campus. The schema also stores per-pair rules (Annex → Main allowed, Main → Annex blocked), and the mobility check honours them, but the current screen exposes only the school-wide default; per-pair overrides are a planned enhancement called out in the roadmap below. Every permanent class move and student transfer writes an append-only history row, so the trail of who moved where, when, and why is always reconstructable.

A school-wide role makes you the same everywhere. A campus-scoped role makes you a principal on one campus and nobody special on the next. This is the heart of federation, and it lives in the campus_role_assignments table.

You grant a campus role in two places — both write the same row. Open a campus and go to its roles surface (the campus-roles admin under /dashboard/campuses/[id]/roles), or use the scope picker in the central roles page at /dashboard/roles. Pick the staff member, pick the role, add a rationale; YESS records the grant with an effective-from date and an optional allowance. Revoking does not delete the row — it sets it inactive and stamps an effective-to date, preserving the audit trail.

YESS seeds four campus-native role kits per school — campus principal, vice-principal, operations, and admissions — each pre-filled with a sensible permission set, alongside the school-wide campus manager role. The assign dialog sorts these campus-native roles to the top with a badge, but any custom role can be granted on a campus too.

On the client, the same logic is exposed as hasCampusPermission(action, campusId) and scopedCampusIds(), so a screen hides the buttons a campus manager cannot use and shows only the campuses they can reach — the UI and the database agree because they read the same grants.

Click a campus from the roster and you land on its own little world at /dashboard/campuses/[id]: an identity header, four KPIs (students, staff, classes, rooms), and a grid of cards that lead into everything that campus owns. Some cards open a dedicated admin surface; others are filtered deep-links that carry the campus into another module so you see only that site's slice.

The detail page also carries quick-actions and cross-links into students, staff, classes, timetable, and transport — each pre-filtered to the campus — so the campus becomes a hub you steer the whole school from while never leaving its scope.

A federation only works if a campus can be a little different. The campus_settings table — one row per campus — lets each site override the school defaults at /dashboard/campuses/[id]/settings. The overrides that matter most day to day:

The attendance lock grace (how many minutes after the bell a teacher can still mark the roll), whether the campus allows walk-in admissions, its own contact and emergency details, and — stored as validated JSON — its own bell schedule and calendar overrides. A campus can keep a later start, a different term-break, or a stricter attendance window than its siblings. Leave a field empty and the campus simply inherits the school-wide value; there is no need to restate what is already true.

The same pattern reaches finance and HR: a campus can carry its own fee scale and its own timetable template, and per-campus P&L and collection figures are computed from the campus_id stamped on invoices, payments, journal entries, and expenses — so "how is the Annex doing" is a real, isolated number, not an estimate.

Two campus-aware features close the loop between "who is physically here" and "what each person is allowed to touch."

Campus presence

The presence roster at /dashboard/attendance/campus-presence answers a question single-site schools never have to ask: who is on this campus today? It is built from the timetable — a database function walks every period scheduled into a room on the chosen campus and returns every staff member teaching there, with a period count. A teacher who is home-based on the Main Campus but covering a class at the Annex shows up on the Annex roster, because presence follows the schedule, not the staff record.

Exam isolation

Some federations want a hard wall around assessment: a campus-assigned teacher should never see another campus's exam papers, mark sheets, or report cards. YESS ships an exam campus isolation toggle on the campuses page. Switch it on and a restrictive rule limits campus-scoped staff to their own campus's exams and gradebook — while school-wide leadership still sees everything. Off by default, so smaller federations are not boxed in.

Everything above scopes people down to their campus. The owner portal does the opposite — it rolls every campus up into one comparison. At /owner/campuses the proprietor sees each campus ranked side by side on the three numbers that decide whether a site is healthy: enrolment, fee collection rate, and presence.

The comparison is computed by a single database snapshot that returns one row per campus — student count, staff count, attendance rate, billed, collected, and collection-rate percentage — so the ranking is live and the owner never waits for a report. This is the federated view multi-campus exists to produce: a campus manager runs their gate; the owner reads them all.

Multi-campus federation is built as a multi-node initiative; identity and membership, scoped RBAC, campus-aware data and RLS, finance and HR scoping, timetable, presence, and the owner comparison are live today. The honest gaps below are tracked and will land in upcoming releases.

Multi-campus is a cross-cutting dimension: it touches almost every operational module by adding a campus to its scope.