Skip to content
All modules Platform & Settings

Branch Management software for Indian schools

Run multiple campuses

Feature identity

Branch Management

An illustration, not a screenshot. The interactive example below shows what this capability actually does.

Example view

Branch Management in a school workflow

Run multiple campuses

Platform & Settings
Branch Management in a school workflow
Platform & Settings
  1. 01
    Required context

    A plan that includes Group & Chain, plus a configured legal-entity membership model must be confirmed before rollout.

  2. 02
    Supported work

    Cross-school comparison table plus group-wide roll-up KPIs.

  3. 03
    Reviewable result

    A group-level view of member schools with governed cross-campus comparison, transfers, branding and consolidated billing evidence.

Example record

Branch Management

Authorised view
  • Cross-school comparison table plus group-wide roll-up KPIs
  • Consolidated monthly billing statement with per-school lines and CSV
  • Consent-gated student transfers that keep one identity across campuses
  • A group-wide white-label brand every campus inherits, with per-school overrides
A group-level view of member schools with governed cross-campus comparison, transfers, branding and consolidated billing evidence.
Code-native illustrative example · not live product UI · no customer dataExample labels and outcomes come from this capability's reviewed catalogue record.

Product scope

What it does

A trust or chain running several schools gets one group console: a cross-school roster with per-school KPIs (students, fee outstanding, plan), a group-wide roll-up, and one consolidated billing statement per month. Students transfer between member schools through a guardian-consent-gated request that carries their APAAR/UDISE identity — and one group can never see another's data.

The school problem

School teams need a dependable way to handle Branch Management: Run multiple campuses. The required records, assigned roles and review boundary must remain explicit.

Day-to-day work

How your school uses it day to day

Run multiple campuses.

  1. Cross-school comparison table plus group-wide roll-up KPIs
  2. Consolidated monthly billing statement with per-school lines and CSV
  3. Consent-gated student transfers that keep one identity across campuses
  4. A group-wide white-label brand every campus inherits, with per-school overrides

Operational result

What your school gets

A group-level view of member schools with governed cross-campus comparison, transfers, branding and consolidated billing evidence.

Access and ownership

Who typically uses it

  • Trust owner
  • Group administrator
  • Campus head
  • Group finance manager

What each person can actually see depends on the role you give them and which classes or records you assign.

Availability and setup

What to confirm before rollout

Included from Enterprise

Governed multi-school and group-level administration.

  • A plan that includes Group & Chain, plus a configured legal-entity membership model
  • Requires Group & Chain on a plan that includes it, and a confirmed multi-school governance model.

Flagship workflow deep dive

Multi-Campus Governance & Group Oversight

One group view. Every campus stays bounded.

Give a trust or school chain a legal-entity-scoped view of member schools, student counts, fee exposure, plan state and group operations. Central oversight stays read-oriented; campus writes continue through each school's own roles, permissions and operating controls.

Interactive operating model

The bounded campus network

Follow one group operation from legal-entity scope to a campus outcome without collapsing tenant boundaries.

Illustrative workflow · no customer data

Stage 1 of 5

Group resolved

The request resolves the caller's legal entity and its authorised member-school list.

Control point

A school outside that group cannot be read or selected as an operation target.

Evidence retained

Legal entity, group role and member tenant IDs.

Core workflows and features

The operational work behind the promise

  1. Member-school rosterReview the schools attached to the legal entity with each campus's status, plan and academic context.
  2. Per-campus KPIsCompare current student count, each school's Vidyapeeth360 subscription cost and open fee-outstanding evidence by member school.
  3. Group roll-upAggregate schools, active schools, students, Vidyapeeth360 subscription cost, outstanding fees and plan mix inside the caller's group scope.
  4. Request-time comparisonCompute the supported comparison from each member tenant context instead of persisting a marketing estimate.
  5. Consolidated subscription statementGenerate one monthly legal-entity statement with per-school lines in exact paise and a CSV export.
  6. Frozen final statementsPrevent a paid or cancelled group statement from being silently regenerated with different point-in-time values.
  7. Consent-gated student transferOpen an intra-group transfer only after guardian consent is acknowledged, then require an authorised approve or reject decision.
  8. Shared identity continuityCarry the shared person identity and recorded APAAR or UDISE values into the target enrolment while closing the source after approval.
  9. Group brand inheritanceApply the legal entity's brand defaults to member schools while respecting an authorised campus override.
  10. Paused SOP pack rolloutInstall a versioned operations pack across member schools; every campus copy starts paused for local role and timing review.
  11. Compliance roll-upCompare current due, due-soon, in-progress and overdue compliance-calendar counts by member school.
  12. Failure-isolated rolloutRetain a per-campus success or failure result so one school's transient error does not silently conceal the rest of the group operation.

Deterministic group governance

Centralise oversight without inventing a group-wide AI authority.

The group console uses legal-entity scope, deterministic roll-ups and explicit transfer or rollout decisions. Aira may remain available inside separately authorised campus workflows, but it does not gain trust-wide access from this module.

  • Calculate group summaries and campus comparisons from member-school records inside the caller's legal-entity boundary.
  • Require guardian consent before a transfer request and a separate authorised approval before the target record is created.
  • Install group SOP templates in a paused state so each campus can review roles, times and local operating fit.
  • Keep customised campus SOP items from being silently replaced during a later group resync.
  • Return per-campus rollout results and current compliance-calendar counts for human follow-up.

Human boundary

There is no group-wide Aira command surface in this module. Group oversight does not grant unrestricted campus writes, and Aira on one school's plan does not widen its role or record scope to the trust.

Key daily uses

What the school team does here

  1. Compare current student and fee-outstanding evidence across member schools.
  2. Generate or export the group's monthly subscription statement.
  3. Review due-soon and overdue compliance items by campus.
  4. Install a school-operations SOP pack for campus-level review.
  5. Process a guardian-consent-backed inter-school transfer.

Used by

  • Trustee
  • Group administrator
  • Central operations lead
  • Group finance leader
  • Campus principal
  • School tenant administrator
  • Authorised transfer reviewer

Actual access follows the school's plan, role permissions and record scope.

Measurable operating indicators

Metrics to track — not guaranteed ROI

Establish a baseline before rollout, agree the reporting period, then compare the school's own source evidence.

Group coverage

Member schools, active schools and current student count

Shows the current operating footprint inside the legal entity's authorised scope.

Operational exposure

Open fee-outstanding value plus due-soon and overdue compliance counts by campus

Makes campus-level attention areas visible without turning them into an AI risk score.

Governed rollout

Pending or completed transfers and SOP rollout success or failure by school

Tracks whether a central action reached each campus and where a human needs to intervene.

Prerequisites and availability

Confirm the operating context before rollout.

Group & Chain on a plan that includes it · confirmed legal-entity and member-school model

  • Confirm the legal entity, member tenants, group roles and campus-specific role boundaries before enabling the console.
  • Cross-campus writes still require the relevant group action and each workflow's own validation; oversight is otherwise read-oriented.
  • Student transfers require acknowledged guardian consent, source and target membership, and an authorised review decision.
  • SOP templates arrive paused; each campus must review local ownership, timing, holidays and proof requirements before activation.
  • Aira remains tenant- and role-scoped; no group-wide Aira capability is implied.

Connected operating context

Available workflows

These are the documented neighbouring capabilities that school teams may review with this module. A related page does not imply that every hand-off is automatic or enabled in every plan.

Explore all modules

Buyer questions

Frequently asked questions

The questions school owners ask before they subscribe: what it does, who can see it, and what to set up first.

Can a group administrator see every school on the platform?

No. Group access is scoped to one legal entity, so an administrator sees only the member schools of their own group. That boundary is enforced on the server for every group request, not by hiding links in the interface.

Does each school keep its own branding and configuration?

Yes. A member school can override the group's branding, and configuration such as board and grading stays per school. The group layer adds roll-up, consolidated billing and intra-group transfers on top of schools that remain distinct.

Does Branch Management work on its own?

Branch-wise Reports, Institute Settings, Role & Permission, Student Admission are the documented neighbouring capabilities. They help a school evaluate the surrounding hand-offs, but a related page does not mean every integration is automatic or included in every plan.

What should our school prepare before enabling Branch Management?

A plan that includes Group & Chain, plus a configured legal-entity membership model. Requires Group & Chain on a plan that includes it, and a confirmed multi-school governance model.

Is AI used in Branch Management?

No AI capability is asserted for Branch Management. Its documented work remains controlled by school records, roles and permissions.

How do we confirm the plan and implementation scope?

Branch Management is included from Enterprise in the current public plan matrix. Final rollout scope, services and external dependencies are confirmed in your written proposal.

See it in your school context

Run branch management the connected way.

See how this workflow fits your school's current records, roles, plan and rollout requirements.