Skip to main content
Schoolyi

Partial support - read the limits before you shortlist us on it

Multi-school management

A deployment can hold several schools, each with its own identity and settings. It does not scope rosters, fees, or payroll per campus, and it does not report across them. Groups usually mean two different things by multi-campus: several schools administered together, and each campus's data partitioned from the others. We support the first and not the second. Classes, academic years, fee structures, payroll, and boarding records carry no campus identifier, a user belongs to one school, and only a platform administrator can switch between schools. There is no group-level report. A group that needs real per-site partitioning should run a deployment per campus.

School IT administrator managing secure access and roles

Outcomes

What changes when multi-school management is live

Practical results schools report after rolling out multi-school management inside platform & access.

  • Several schools on one deployment, each with its own branding and settings

    Groups avoid separate logins for every campus

  • Platform-administrator school switching - not available to ordinary staff

    Campus teams keep daily records correctly scoped

  • Role permissions enforced within a school

    Leadership can standardise rollout decisions

  • Activity log records the school context

    Shared patterns reduce repeated setup work

Product truth

What to verify before rollout

Good school software copy should answer who owns the work, what the handoff produces, and which parts still depend on deployment decisions.

Validate for your rollout

Capability status

This page describes the supported workflow boundary. Confirm configuration, integrations, data, and policy requirements in a representative pilot before committing to production.

Teams in the workflow

  • Group leadership
  • IT coordinators
  • Campus administrators

Deep dive

Decisions, handoffs, and boundaries

Use these details to turn a product page into an implementation conversation.

Why schools upgrade multi-school management

Groups usually mean two different things by multi-campus: several schools administered together, and each campus's data partitioned from the others. We support the first and not the second. Classes, academic years, fee structures, payroll, and boarding records carry no campus identifier, a user belongs to one school, and only a platform administrator can switch between schools. There is no group-level report. A group that needs real per-site partitioning should run a deployment per campus.

Connected to platform & access

A deployment can hold several schools, each with its own identity and settings. It does not scope rosters, fees, or payroll per campus, and it does not report across them. Because multi-school management lives inside platform & access on Schoolyi, teams stop reconciling exports between spreadsheets and the parent portal.

Evidence layer

Read the supporting product and implementation material before making a capability claim.

Key capabilities

Everything included in this capability, from daily workflows to exports your team relies on.

  • Several schools on one deployment, each with its own branding and settings
  • Platform-administrator school switching - not available to ordinary staff
  • Role permissions enforced within a school
  • Activity log records the school context
  • No campus identifier on classes, fees, payroll or boarding records
  • No reporting that aggregates across schools

Who uses this

Role-scoped workspaces so each team sees only the tasks they own.

  • Group leadership
  • IT coordinators
  • Campus administrators

Full module

Platform & access

Every user gets the right access from day one. Schoolyi gives administrators fine-grained control over who can view and change student records, fees, exams, and settings, so each role sees a workspace built for their job.

Explore Platform & access

Workflow

How teams run multi-school management week to week

A typical path from setup through daily use on Schoolyi.

  1. 01

    Several schools on one deployment, each with its own branding and settings

    Part of the Multi-school management workflow on Schoolyi, connected to roster, calendar, and role permissions.

  2. 02

    Platform-administrator school switching

    not available to ordinary staff

  3. 03

    Role permissions enforced within a school

    Part of the Multi-school management workflow on Schoolyi, connected to roster, calendar, and role permissions.

  4. 04

    Activity log records the school context

    Part of the Multi-school management workflow on Schoolyi, connected to roster, calendar, and role permissions.

Deep dive

Built for school operations, not generic ERP

Long-form context for evaluators comparing capabilities during an SMS rollout.

School IT administrator managing secure access and roles

Why schools upgrade multi-school management

Groups usually mean two different things by multi-campus: several schools administered together, and each campus's data partitioned from the others. We support the first and not the second. Classes, academic years, fee structures, payroll, and boarding records carry no campus identifier, a user belongs to one school, and only a platform administrator can switch between schools. There is no group-level report. A group that needs real per-site partitioning should run a deployment per campus.

School finance manager reviewing fee records and receipts in an administration office

Connected to platform & access

A deployment can hold several schools, each with its own identity and settings. It does not scope rosters, fees, or payroll per campus, and it does not report across them. Because multi-school management lives inside platform & access on Schoolyi, teams stop reconciling exports between spreadsheets and the parent portal.

Related capabilities

These areas work closely with multi-school management inside platform & access.

Questions, answered

Straightforward answers for visitors evaluating the product.

What does multi-school management support?+

One deployment can hold several schools with separate identity and settings, including each school’s branding and configuration.

Test the answer with a representative record and role before making it part of a live term workflow. Capture the expected result and the exception path so the team can verify it after launch.

Are campus rosters and fees partitioned?+

No. Classes, fees, payroll, and boarding records do not carry a campus identifier, so groups needing strict per-site partitioning should use a deployment per campus.

Treat that boundary as an explicit procurement or deployment decision. Document the responsible owner and any supporting process before rollout.

Who can switch between schools?+

Only platform administrators can switch school contexts; ordinary staff remain within their assigned school and its role permissions.

Record the responsible administrator and verify the control in the target deployment before production data is loaded. Keep the evidence with the school’s procurement or access-review record.

Are there group-wide reports?+

There is no reporting aggregate across schools, which is an explicit boundary to validate before choosing this deployment model.

Test the answer with a representative record and role before making it part of a live term workflow. Capture the expected result and the exception path so the team can verify it after launch.

Students walking together across a school campus at sunset

See Multi-school management in a live walkthrough

We'll show how multi-school management fits your school's platform & access workflows and which teams benefit first.

Already using Schoolyi? Sign in