Multi-Campus School Management — What Breaks When You Open a Second Branch

The week it breaks

With one campus, almost every question has an unambiguous answer. “How many students do we have?” is a number. “Show me Class 8-A” returns one class. “Who is the principal?” is one person.

Open a second branch and every one of those questions grows a qualifier. How many students — here, or across the group? Class 8-A at which campus? Which principal? The systems do not fail loudly. They keep returning answers, and the answers are quietly wrong or quietly incomplete, which is worse.

The specific things that break first, in roughly the order groups hit them:

• Class names collide. Both campuses have a Class 8-A. Attendance, timetables and marksheets now need to say which one.
• Admission and roll numbers collide. Two students end up with the same admission number because each branch was numbering independently.
• Staff lists merge badly. The North campus office sees South campus teachers in their dropdowns and picks the wrong one.
• Fee reports stop being actionable. A group-level defaulter list is useless to a branch accountant who can only chase their own parents.
• Parent communication leaks. A circular meant for one branch goes to every parent in the group.

The three approaches groups try

Nearly every multi-branch group arrives at one of these three. Two of them cost more the longer you stay on them.

What “scoped by campus” actually means

This is the distinction that separates real branch management from a branch-shaped filter, and it is worth being precise about when you evaluate any system.

A filter is something the user chooses. They pick a campus from a dropdown and the list narrows. They can pick a different one. It is a convenience.

Scoping is something the system decides. The user's campus is attached to their account, and every query they make is restricted to it before it reaches the database. There is no dropdown, because there is nothing to choose. If a campus principal edits the URL to point at another branch, they get nothing back.

The test is simple: can a branch user reach another branch's data if they try? If the answer is “only if they change a setting”, you have a filter. That is fine for convenience and useless for control.

Deciding who sees what

Most groups need only two levels, and adding more before you need them creates work without adding safety.

• Campus-level. Principals, teachers, office and accounts staff attached to one branch. They see their branch and nothing else. This is the large majority of your users.
• Group-level. Trustees, the group director, a central accounts or HR team. They see everything, and can narrow to one branch when they want to.

The case that needs a deliberate decision is staff who genuinely work across branches — a visiting music teacher, a shared counsellor, a central accountant. Pin them to one campus and they vanish from the other branch's timetable. Leave them at group level and they appear in both, which is usually what you want. Decide this per person when you set up, rather than discovering it when a timetable comes out wrong.

On paper, your branches are separate schools

This is the part that surprises groups most, and it is worth checking early because it shapes how you set your records up.

A trust or society can run several schools, but recognition, codes and affiliation are generally granted per school, not per trust. In practice that usually means each branch has its own UDISE+ code, files its own returns, holds its own board affiliation number, and carries its own RTE obligations. Your group is one organisation commercially and several schools administratively.

The practical consequence for your systems: student identifiers, fee books and academic records should be recorded per campus from the beginning. Retrofitting a branch identity onto records that were created without one is considerably more painful than setting it up on day one.

What group-level reporting has to answer

Consolidated reporting is the entire reason for keeping one system. If it cannot answer these without a manual merge, it is not doing its job:

• Headcount by branch, and the group total, on the same screen.
• Fee collection and outstanding by branch — so you can see which branch is behind, not just that the group is.
• Staff-to-student ratio per branch, which is where uneven hiring shows up first.
• Attendance trends side by side, so a dip at one campus is visible against the others rather than averaged away.
• Results by branch, for the same reason.

Averaging is the enemy here. A group-level number is often the least useful figure on the page: two branches at 92% and 68% attendance report the same group average as two branches at 80%, and only one of those situations needs your attention this week.

Three decisions to make before you switch branching on

These are the ones that cause trouble later if they are left to default.

• What happens to unassigned records. Any student or staff member not attached to a branch belongs to no branch, so branch users will not see them. That is the correct behaviour — but only if your system tells you how many such records exist. Otherwise they silently disappear from every view at once.
• Whether numbering is per branch or per group. Admission numbers, invoice numbers and roll numbers all need an answer. Per branch is usually right, and usually needs a branch prefix so numbers stay unique across the group.
• Who can create and close branches. This should sit with group management only. A campus principal should not be able to open a new campus, and should not be able to close one that still has students in it.

Setup checklist for a school group

• Create each branch as a distinct campus with its own code before moving any records
• Record each branch's UDISE+ code, affiliation number and recognition details separately
• Assign every existing student to a campus — then check the unassigned count is zero
• Assign every staff member, and decide deliberately about anyone who works across branches
• Attach each class and section to its campus so 8-A is unambiguous
• Give admission, roll and invoice numbers a branch prefix
• Restrict branch staff to their own campus; leave group management unrestricted
• Confirm circulars, fee reminders and SMS default to one branch, not the whole group
• Check that group reports show branch-by-branch figures, not just group averages
• Confirm your Transfer Certificate process before the first student moves between branches

Do it before you need it, not after

The cheapest moment to set branch management up is while the second campus is still small. Assigning two hundred students to a campus is an afternoon; assigning two thousand across four branches, after two years of mixed records, is a project. The work does not get harder because branching is complicated — it gets harder because every month adds records that were created without a branch, and each one has to be tracked down and corrected by hand.