Multi-campus governance without one-size-fits-all workflows
Networks need comparable records and consolidated oversight. Campuses need calendars, services and approval paths that reflect local reality. The architecture should make both levels explicit.
Centralising every choice creates workarounds. Letting every campus define its own data creates reports no one trusts. Multi-campus design works when the institution separates the standards that must be shared from the workflows that may differ.
The useful question is not central or local. It is which level owns each definition, rule, transaction and exception. That ownership should be visible in configuration and reporting.
Federated operating model
The network publishes shared definitions; campuses operate inside approved local scope; consolidated evidence returns with context.
Share definitions before dashboards
A consolidated dashboard cannot repair inconsistent definitions. Agree what active student, outstanding balance, attendance rate and completed credit mean across the network. Store the definition and version beside the measure.
Campuses may still need local dimensions, but the shared core must remain comparable. A local category can map to a network category without being erased.
Delegate configuration with boundaries
A campus may own its calendar, rooms, service catalogue and approved fee variants. The network may own identity rules, core programme structures, access principles and financial reporting. Document which configuration is inherited, locally editable or centrally locked.
Changes need effective dates. A new network policy should not silently rewrite transactions created under the earlier policy.
Preserve context during movement
A learner or staff member moving between campuses should keep identity and history while receiving new local roles, services and obligations. Avoid exporting a PDF and creating a second person.
Transfer workflows should map courses, balances, holds and documents, then record what was accepted, converted or left with the originating campus.
Questions to settle before configuration.
- Define the network data dictionary.
- Classify configuration as inherited, local or locked.
- Effective-date policy and configuration changes.
- Keep campus context on every transaction.
- Design transfer mappings before enabling mobility.
- Test consolidated reports against campus source totals.
Sources behind this field guide
These links explain the standards, regulations or evidence referenced above. Product choices should still be tested against your institution's own policy and jurisdiction.