Databus Logo
Blog Login →
The Group-Oversight Scenario for Trust Heads & Group CEOs

Five schools, a board meeting at 11, and one question: which campus needs you today?

This is the scenario of running several schools at once — one cross-campus morning view that surfaces the school needing attention, across fees, admissions, results and staffing, instead of phoning five principals or waiting for five monthly reports. A use case that routes to each module.

For Trust chairmen, group CEOs & society directors · cross-campus triage · routes to per-school analytics + the Trust finance hub · a scenario, not a module.

See the cross-campus view →
In plain English

This is the use-case scenario for the person running several schools at once — a Trust chairman, group-CEO or society director. The job is group oversight: one cross-campus view that answers which school needs attention today, before the governing-body meeting, instead of five phone calls. It's a scenario that routes to the modules, not a module itself. The operational mechanism that makes several schools run as one system — Super Admin, branch access fencing, central fee-policy push, consolidated P&L roll-up — is the multi-branch feature. Per-school drill-down is the school-analytics-reporting solution; consolidated Trust finance is finance-management; the access model is role-based-access. This page is the buyer scenario that ties them together.

One view, not five calls
every campus
side by side
Triage, not averages
the campus that's
off-trend, surfaced
Routes to detail
drill-down → analytics
money → finance hub
A scenario
not a module —
it orchestrates them
A real Monday · education Trust · 5 campuses · 09:40, board meets at 11

The cross-campus view — and the one school it tells you to look at.

Mrs Rajagopal chairs a Trust running five schools. Before the governing-body meeting, she opens one view. Most campuses are fine; the value is that it points her at the one that isn't — and then hands her into the right module for the detail.

Group view · 5 campuses · Monday 09:40 · pre-board Cross-campus triage
CampusFees this cycleAdmissions (season)Results trendStaffing
City Campuson trackaheadsteadyfull
North Campuson trackslightly slowsteadyfull
Lake Campuslaggingbehind targetdip last term2 vacancies
South Campuson trackon targetsteadyfull
New Town Campuswatchon targetsteadyfull
Four campuses are fine — the view's job is that Lake Campus stands out across three columns at once, which no single monthly report would have shown her this morning. From here she drills into Lake's numbers in per-school analytics, checks the Trust money position in finance-management, and walks into the board meeting knowing exactly which campus needs a decision. The view triages; each module explains.
Where running a school group goes wrong

Four ways a Trust head flies blind across campuses.

Five phone calls every morning

With no group view, the only way to know how each school is doing is to ring each principal — who each give a reassuring answer, so the campus quietly drifting is the last one you hear about.

Five reports, a week late

Each school sends its own monthly report in its own format, arriving after the problem has already grown. By the time the numbers are comparable, the term is half over.

Averages that hide the outlier

A group "total" looks healthy because four strong campuses mask one weak one. The Trust head needs the outlier surfaced, not blended into a comfortable average.

No comparable standard

Each campus runs fees and report cards its own way, so "behind on collection" means something different at each, and a parent moving between campuses meets a different system each time.

How a Trust head reads the group

One view, then into each module for the detail.

1

Open the group view, not five logins

Instead of phoning each principal, the Trust head opens one view showing every campus side by side. The login partitioning that makes this one system across schools — Super Admin, branch fencing — is the multi-branch feature; this scenario is what the head does with that single view.

2

Spot which campus needs attention today

The view surfaces the campus that's off-trend — fees lagging, admissions slow, a results dip, a staffing gap — so attention goes to the one school that needs it rather than being spread evenly across five that are mostly fine.

3

Drill into that one school's numbers

Having spotted the campus, the head drills into its detail — fee-collection rate, attendance, result trends — which is the per-school analytics view, owned by the school-analytics-reporting solution. The group view points; the per-school dashboard explains.

4

Check the consolidated Trust finances

For the money question — how the Trust is doing across campuses, budgets versus actuals, the position for the auditor — the head goes to the consolidated financial hub, owned by the finance-management feature. The group view flags; finance-management consolidates.

5

Walk into the board meeting with the picture

By 11, the head has the group picture and the one or two campuses that need a decision — drawn from the real modules, not five hurried slide decks. This scenario is the orchestration; each number it shows is owned and produced by its own module.

What a use case is, on this estate

A scenario that orchestrates modules — it doesn't replace them.

It routes, it doesn't re-describe

A use-case page is the buyer's end-to-end scenario. It points at the modules that do the work — multi-branch, analytics, finance — rather than re-explaining any of them. The detail lives on each module's own page, and this page links there.

Each school keeps its own data

The Trust layer sits above for oversight; it doesn't merge the schools into one pool. Each campus keeps its own students, staff and records under DPDP Act 2023, with the group head's access governed by role-based rules.

Comparable, by standardisation

Campuses are comparable because fee policies and report-card formats are standardised through the modules that own them — central fee-policy push in multi-branch, formats in academics — so "behind on fees" means the same thing everywhere.

Framework references: DPDP Act 2023 (each school's data stays that school's; group access is role-governed). This is a use-case scenario, not a separate product or module — it is a way of using SchoolDeck that a multi-school Trust buys. The multi-school operational mechanism is owned by the multi-branch feature; consolidated finance by finance-management; per-school dashboards by the school-analytics-reporting solution. This page orchestrates and routes to them.

Scenario vs mechanism vs finance vs analytics · what this page owns

Group-oversight scenario ≠ the multi-branch mechanism ≠ the Trust finance hub ≠ per-school analytics.
This page owns the scenario; the rest are their own pages.

SchoolDeck keeps the multi-school scenario and the multi-branch mechanism as separate pages on purpose — the head term "Multi-Branch School ERP" belongs to the feature, so this use case ranks for the group-oversight scenario instead and never competes with it.

This page owns

  • The group-oversight scenario — running several schools as one job.
  • The cross-campus triage — surfacing the one campus that needs attention.
  • The pre-board morning view a Trust head actually uses.
  • Routing into the right module for each detail.
  • The group-head buyer voice (Trustee / group-CEO / director).

This page defers to

  • The multi-school operational mechanism — Super Admin, branch RBAC fencing, central fee-policy push, P&L roll-up — lives in Multi-Branch (feature). It owns "Multi-Branch School ERP"; this page is the scenario.
  • Consolidated Trust finance — executive hub, budgets vs actuals, Tally bridge — lives in Finance Management. This page flags; that page consolidates.
  • Per-school dashboards — one campus's fee/attendance/result drill-down — live in School Analytics & Reporting. The group view points; that page explains.
  • The access model — who-sees-what within and across schools — lives in Role-Based Access.
Three group-oversight realities

The same scenario, three kinds of group.

The cross-campus view is the same; the shape of the group shifts the emphasis.

Education Trust

Several schools, one board

A charitable Trust running several schools needs the group head ready for the governing-body meeting with a comparable picture across campuses — and the consolidated finance, in finance-management, ready for the same audit.

School chain

A standardised brand across cities

A school chain wants every campus run to the same standard, so fee policies push centrally and report cards look the same — the standardisation owned by multi-branch, the comparison surfaced in this view.

Society with branches

One society, a few campuses

A society running two or three campuses gets the cross-campus view without heavy structure — spotting the branch that's lagging early, then drilling into it via per-school analytics.

From the field

Coimbatore, Tamil Nadu · education Trust · chairman, five campuses.

"I chair a Trust that runs five schools, and for years my Monday mornings were five phone calls — and every principal, naturally, told me things were fine. The one campus that was actually slipping was always the one I heard about last, usually when the monthly reports finally landed a week later in five different formats. What I needed was never another dashboard for one school — it was the view across all five, so I could see at a glance which one needed me before the trustees met at eleven. Now I open one screen, and last month it put Lake Campus in front of me — fees lagging, admissions behind, a results dip, all at once — and I went straight into that school's numbers and our Trust accounts before the meeting. I want to be precise about what this is: it isn't a separate module, and it doesn't replace our analytics or our finance system — it's the cross-campus layer that points me at the right one. The detail still lives in those modules; this just makes sure I'm looking at the right school."
Mrs Sarojini Rajagopal Chairman · charitable education Trust (5 campuses) · R.S. Puram, Coimbatore-641002, Tamil Nadu
Cross-campus group view · Monday pre-board triage · routes to per-school analytics for drill-down + finance-management for Trust consolidation · a scenario, not a module
Quick answers

Running a multi-school Trust, asked and answered.

What every Trust chairman, group-CEO and society director asks before running the group on one platform.

What is this multi-school use case about?
It is the scenario of running several schools at once as a Trust chairman, group-CEO or society director — having one cross-campus morning view that answers which school needs attention today, across fees, admissions, results and staffing, before the governing-body meeting. It is a buyer scenario, not a single module. The capabilities it ties together — the multi-school operational mechanism, the consolidated finance, the per-school analytics — are each owned by their own pages, and this scenario routes to them.
How is this different from the multi-branch feature?
The multi-branch feature is the operational mechanism that makes several schools run as one system — the Super Admin role, branch-level access fencing, central fee-policy push, and the consolidated P&L roll-up. This use-case page is the scenario a group head lives: what they actually do with that single system on a Monday morning before the board meets. If you want to know how multi-school access and roll-up are configured, read the multi-branch feature; if you are the Trust head deciding how to run the group, this scenario is your starting point, and it links into that feature.
Does it consolidate the Trust's finances?
It points you to where that happens — it does not duplicate it. Consolidated Trust finance — the executive financial hub, budgets versus actuals, the Tally bridge, Maker-Checker control — is owned by the finance-management feature. This scenario flags, in the group view, that a campus is off on the money side; the actual consolidation and the financial statements live in finance-management. Keeping the scenario and the finance hub on separate pages stops "group oversight" and "the Trust accounts" from being treated as one thing.
How is this different from per-school analytics?
The group view answers "which of my schools needs attention"; the per-school analytics view answers "why, and what exactly is happening at that one school." The drill-down into a single campus's fee-collection rate, attendance and result trends is owned by the school-analytics-reporting solution. This use case is the cross-campus layer above it: it surfaces the campus, and the per-school dashboard explains it. Two altitudes, two pages — the group scenario and the single-school dashboard.
Is this a separate product or part of SchoolDeck?
It is part of SchoolDeck — it is a way of using the same platform that a multi-school Trust buys, not a separate product. A Trust runs each school on SchoolDeck, and the multi-branch capability plus this group-oversight scenario lets the head see across all of them. There is no separate "chain edition"; it is the same modules, with the multi-school operational layer enabled and the group view on top. The scenario describes how a group head uses what is already there.
How does access work across schools — who sees what?
A Super Admin at the Trust sees across campuses; each school's principal and staff see their own school, fenced by branch-level role-based access. That partitioning is the multi-branch feature's job, paired with the role-based-access catalogue that defines who-can-see-what within a school. This scenario relies on it so that the group head gets the cross-campus view while a class teacher at one school still only sees their own classes. The access model is owned by those features; this page is the use of it.
Can it standardise fees and report cards across campuses?
Yes, through the modules it routes to. Central fee-policy push — setting a policy once and applying it to every campus — is part of the multi-branch feature; report-card formats are standardised through the academics and examinations modules each school runs. This scenario is why a group head wants that consistency (so campuses are comparable and a parent moving between them sees the same standard); the mechanism that enforces it lives in those feature pages, which this page links to.
Does each school keep its own identity and data?
Yes. Each campus keeps its own students, staff, fees and records as its own school; the Trust layer sits above for oversight and consolidation, it does not merge the schools into one undifferentiated pool. A student belongs to their campus; the group view aggregates across campuses without dissolving them. This matters for both clarity and compliance — each school's data stays that school's, under DPDP Act 2023, with the group head's access governed by the same role-based rules.
What does a Trust head get that single-school software doesn't give?
The cross-campus altitude. Single-school software answers questions about one school; a Trust head's real problem is comparison and triage across several — which campus is lagging on fees this month, which had a results dip, where a staffing gap is opening — without logging into five systems or waiting for five reports. This scenario is that altitude, drawing on the multi-branch operational layer and routing into the per-school detail. It is the difference between running five schools and running a group.

Stop ringing five principals every Monday.
See the whole group in one view.

We'll show you the cross-campus group view, how it surfaces the one campus that needs attention, and how it routes into per-school analytics and the Trust finance hub — in a demo set up on a multi-school structure like yours.

Book the Group-Oversight Demo →