Running a multi-campus school group on one platform
Each campus wants autonomy, the group wants comparable numbers, and both are right. What to share, what to keep local, and why group completion figures lie.
A school group running several campuses has two correct instincts pulling against each other. Each campus knows its own staff, families and timetable, and every decision taken for it at head office arrives slightly wrong. The group needs figures it can compare across campuses, which is impossible unless some definitions are identical in every building. The workable split is narrower than most groups expect: share the things that must mean the same thing everywhere — curriculum structure, assessment standards, and the definition of every reported figure — and keep local everything that touches a person's week.
Most consolidation projects fail on the second half of that sentence. The group buys one platform, then uses it to standardise things that were never the problem — timetables, class names, the word for a school year — while leaving the meaning of completion, attendance and mastery to each campus. That is backwards, and it produces a group dashboard nobody trusts and heads of school who quietly route around the system.
Both sides of the argument are right
The campus argument is about accuracy. A head of school is accountable for results in one building, with one staff list, one intake and one set of local pressures. Anyone who has had a timetable dictated by a central team two hundred miles away knows how much detail does not survive the trip. Autonomy here is not politics; it is how the data stays true to the building.
The group argument is about comparability. If three campuses report a pass rate, someone has to put those numbers on one page and act on the difference. Without comparable figures, a group is a shared logo and a shared payroll, and every improvement found in one building stays there. The campus wants control of operations; the group wants control of meaning.
Federated school group
A group of schools where a small central layer owns a fixed set of shared definitions — curriculum outcomes, assessment standards, and the rule behind every reported figure — and each campus owns everything else: its staff, classes, calendar, language and day. It sits between a centralised group, where head office configures each campus, and a holding company, where campuses share an owner but nothing operational. What defines it is how short the shared list is, not how much the centre controls.
What to share, and what to keep local
Shared: four things
- The curriculum spine. Subjects, sequence and the learning outcomes a school is accountable for. Campuses can teach it differently; they cannot each keep a private outcome list, because a competency recorded at one campus has to mean the same thing when a family moves across town.
- Assessment standards. Rubrics, grade boundaries, and what counts as evidence of mastery. If the standard is local, the grade is local, and comparing results across campuses is comparing marking cultures.
- Reporting definitions. What counts as a completion, an absence, an active learner, an overdue module. Groups skip this one, and it decides whether the group layer is worth having.
- Data policy. Retention, consent, who may see what, and how a subject access request gets answered. A regulator asks the group, not the campus.
Sharing means one definition, one owner and one change process. It does not mean one timetable or one lesson plan. A shared rubric does not stop a teacher teaching. The centre owns the meaning of the word; the campus owns what happens underneath it.
Local: everything that touches a week
- Staff, roles and rights. The people who need administrative access are the ones on site. A head of year should not wait two days for a central ticket to create a class.
- Groups and classes. Cohorts change on a local calendar, for local reasons, sometimes weekly.
- The calendar. Terms, holidays, exam weeks and reporting cycles differ between campuses in one group more often than head office expects, and always between countries.
- Terminology. Year 7 or Grade 7. Term or semester. Form tutor or homeroom teacher. This looks cosmetic and is not: staff stop trusting a system that calls things by the wrong name.
- Local materials and family communication. The letter home is written by someone who knows the family.
Should campuses have their own administrators, or should the group office run everything?
Campuses should have their own administrators, scoped to their own campus, with a smaller number of people at group level whose rights reach across all of them. The failure of a central-only model is not security, it is latency — a ninety-second change waits two days. The failure of a campus-only model is that no question about the whole group can be answered without asking eleven people. Both are avoided by attaching rights to a position in the structure rather than granting them campus by campus.
Branches and sub-organisations are not the same thing
Once the shared list is agreed, the structure has to express it. Two shapes look identical on an org chart and behave differently in a system. Vocabulary varies by vendor; this article uses branch and sub-organisation.
A branch is an operational unit inside one organisation: a campus, a department, a region, a key stage. Everything in the branch tree shares the organisation's members, programmes, roles and branding. The point of a branch is permission flow — a role granted at a branch applies to every branch beneath it. The head of the northern campuses is one grant, not one per campus, and when she moves on there is one grant to revoke.
A sub-organisation is a full child organisation: its own members, programmes, roles, branding, terminology and domain, and it can hold children of its own. It is a boundary rather than a folder. Two sub-organisations can run different curricula and admissions without either being a special case.
One organisation, campuses as branches
Northbridge School one brand, one staff list, one curriculum
├── North campuses branch — regional head: one grant
│ ├── Northbridge Central branch
│ └── Northbridge Riverside branch
└── South campuses branch
└── Northbridge Park branch
One group, schools as sub-organisations
Northbridge Education Group parent organisation
├── Northbridge School sub-org — own domain, own staff
│ ├── North campuses branch, inside that sub-org
│ └── South campuses branch
├── Cedar Academy sub-org — acquired, keeps its own brand
└── Northbridge Online sub-org — own programmes, own intake- Use branches when the campuses are one school in several buildings: one name, one staff contract, one curriculum, one set of policies. A branch tree keeps them comparable by default, because there is only one of everything to compare.
- Use sub-organisations when a campus has an identity a parent would recognise — a different brand, a different regulator, its own admissions, its own domain, and staff who should not appear in another campus's user list. Also when the group acquires a school that already has a name and no intention of losing it.
- Use both when the real shape needs both: each school a sub-organisation, and each school's campuses and departments branches inside it.
What is the difference between a branch and a sub-organisation?
A sub-organisation is a separate organisation inside your tenant — its own members, programmes, roles, branding, terminology and domain, and it can contain children of its own. A branch is a unit inside a single organisation, and its purpose is permission flow: a role granted at a branch cascades down every branch beneath it. The quick test is the front door. If the unit needs its own address and its own user list, it is a sub-organisation. If it mainly needs its own manager, it is a branch.
Choosing wrongly costs in both directions. Model everything as sub-organisations and the group loses comparability: four schools, four curriculum trees, four ideas of a passing grade. Model everything as branches and the school that needed its own brand and staff list gets neither. Both are cheap to fix on day one and expensive a year of enrolments later.
The reporting trap
Here is how a group dashboard becomes fiction. The group asks each campus for completion by programme. Campus A counts a programme complete when the learner submits the final assessment. Campus B counts it when a teacher has marked that assessment, a fortnight later. Campus C runs a course with no final assessment and counts it when four fifths of the lessons have been opened. Each rule is defensible on its own site. Averaged, they describe nothing — not learning, not throughput, not marking capacity. It is three different measurements added together.
A wrong number is worse than a missing one, because it gets used. A missing number makes someone ask a question. A wrong one moves staffing, budget and intervention towards the campus with the slowest marking cycle, in a meeting where the figure is on the slide and the definition is not.
Completion is defined once, owned by a named person at group level, and every campus dashboard, export and board paper resolves to that definition.
Completion means whatever each campus's dashboard was configured to mean, and the group figure averages four different questions.
Why don't our campus figures add up at group level?
Almost always because the same word is computed differently at each campus, not because the underlying data is wrong. Completion, attendance, active learner and overdue are the usual four. Before comparing anything, write down the exact rule each campus uses: the event that starts the count, the event that ends it, and what happens to learners who left mid-programme. Groups routinely find three definitions of completion across four campuses, and one of them is counting people who unenrolled.
The fix is not a better dashboard. It is a registry: every reported figure defined once, with a named owner, one source, one aggregation rule and a closed list of dimensions it may be broken down by. Campuses can build any view they like on top of it; what they cannot do is redefine the word underneath. That is what certified metric definitions are for — a metric earns the certified label when a hand-checked expected result sits behind it and is re-run whenever the definition changes, so altering the completion rule breaks a test rather than quietly rewriting last year's figures.
What this looks like at scale
The largest version of this shape running on Lurno — anonymised, because it is somebody else's business — is a K-12 publisher running 114 schools on a single platform. The same structure at a different width is a corporate academy running training for 15 client companies from one tenant. Neither is a special build: a parent organisation holding child organisations, with operational trees inside each child.
Lurno keeps the two trees separate on purpose. Sub-organisations nest, and each carries its own members, programmes, roles, branding, terminology and custom domain with automatic TLS. Branches are the second tree, inside a single organisation, and a role granted at a branch cascades down every branch beneath it. Groups are the third piece: the class or cohort a learner sits in. Which of the three to reach for is set out on white-label and multi-tenancy.
Reporting is a read-only layer over a registry of certified metrics, each defined once with one source and a fixed list of dimensions, so a campus dashboard tile and a figure in the group's board pack cannot be computed two different ways. Every query runs as the person reading it, under the same permissions that govern the rest of the platform, which is what makes it safe to give a head of school live reporting rather than a monthly PDF. That layer is described on reporting and analytics. Separation between schools sits in the database rather than in application code — separation enforced underneath the platform — so a missing filter in a new export returns nothing rather than another school's learners.
Three limits to settle before a group plans a migration. SCORM, xAPI and LTI 1.3 are in development — if your campuses buy publisher content as SCORM packages, ask about timing first. Payments and checkout are in development too, so fees stay in your finance system. And SAML and OIDC single sign-on are on the roadmap rather than shipped; partner sign-on (silent SSO) is available today, which is a different mechanism and worth raising with whoever runs your identity provider. The rest of the model is on Lurno for schools.
Before you consolidate
- List every figure that appears in a group report, and beside each write the exact rule each campus uses today. Reconcile that list before you migrate anything, not after.
- Ask, per campus, whether it needs its own front door and its own user list. That question sorts branches from sub-organisations better than any org chart.
- Name an owner for each shared definition — curriculum outcomes, rubrics, every reported metric. An unowned definition drifts inside a year, and a figure with no owner should not reach a board pack.
- Write down what each campus may change without asking, and publish it. Most resistance to a group platform is about not knowing which decisions are still yours.
- Check that a role granted at group level reaches down, and that a role granted at a campus stops there. Ask to be shown it in the product, not told about it on a call.
- Agree in advance what happens when a school leaves the group: what is deleted, what is exported, and who holds the data in between.
The short version
Share the definitions and keep the operations local. Use branches when campuses are one school in several buildings, and sub-organisations when they are several schools under one owner. And settle what completion means before the first group report is printed — after that the figure is in circulation, and nobody remembers it was three questions.