EDUCATION OPERATIONS · MULTI-BRANCH GOVERNANCE
Multi-Branch Education Management: Separating Branch Operations from Owner Oversight
A clear operating model for keeping school or coaching centre work local while giving authorised owners a distinct view across eligible subscriptions.
THE SHORT ANSWER
Multi-branch management involves two different jobs: running each location’s daily operations and giving an owner a suitable view across the organisation. Separate subscriptions keep operational work with the teams responsible for each branch; a dedicated oversight layer can help authorised stakeholders review eligible information without turning every branch into one shared operational account.
01 / THE CENTRAL QUESTION
Decide what should be common—and what must remain local.
A group with several schools or coaching centres needs more than a count of locations. Owners may want to understand subscriptions, compare selected indicators or prepare an organisation-level review, while each location still manages its own learners, staff, fees and daily decisions. Treating these as one requirement often leads to confusion about who can see or change operational records.
Start by listing decisions at each level. Branch managers need the context to operate their own institution; owners need an agreed set of information for oversight. Then identify where the same term has different meanings between products or locations. This makes it possible to design a useful view without pretending that every branch is identical.
02 / THREE MEANINGS OF MULTI-BRANCH
Separate shared identity, local operations and central oversight.
‘Multi-branch’ may refer to a common organisation, several operational locations, or a central place to review information. A single organisation identity does not mean every employee needs access to every location. Likewise, a consolidated report does not necessarily mean that transactions or student records are maintained in one shared operational workspace.
Write down the meaning behind the request. Is it a way to compare activity, a way to administer user access, or a desire to move learners and fees across centres? These needs have different control and data implications. Product evaluation should distinguish them before a vendor demonstration, especially where schools and coaching centres operate different products and use different definitions.
03 / WHY SEPARATE SUBSCRIPTIONS
Keep branch responsibilities clear instead of hiding them in a shared account.
A separate subscription or account for each location can make responsibility easier to understand: local staff work with the records for the institution they serve, and owners can identify which operating context they are reviewing. It can also make differences between a school and a coaching centre more visible instead of forcing them into an artificial common workflow.
Separation is not automatically a guarantee of security or good governance. Organisations still need to decide who receives access, how roles are reviewed and what information may be shared centrally. A sound architecture describes the boundaries plainly and avoids suggesting that a branch manager can update another location’s operational records merely because the owner can see an overview.
04 / WHAT OWNERS NEED
Give central review enough context to support a decision.
Owners often need subscription-level visibility, a way to locate an institution or branch, and reports that support review across eligible accounts. Useful comparisons require definitions: what period is covered, which product supplies the information, and whether a figure is a total, a rate or a status. Without that context, a visually unified dashboard can invite comparisons that the data does not justify.
Central visibility should also be proportionate. Agree which roles may review organisation-wide data, what can be exported and how information is used in management discussions. A report is a decision aid, not a substitute for asking the branch team what changed or understanding local conditions.
05 / WHAT STAYS BRANCH-LOCAL
Let the operating team own its records and workflow decisions.
Admissions, learner or student records, attendance, fee entries, academic activity and staff administration are part of the location’s ongoing work. The relevant team needs to handle that work in the appropriate School ERP or Campus account, following the organisation’s policies. Keeping the responsibility close to the record helps staff understand who made a decision and which local context applies.
Central oversight should not be described as cross-branch operational control. In CodePex’s architecture, Admin Console supports authorised review across eligible subscriptions; it does not create, edit or delete branch operational records or trigger those product workflows. This distinction should be explicit in requirements, demonstrations, role design and any internal operating guide.
06 / CODEPEX OPERATING MODEL
Connect oversight without collapsing School ERP and Campus together.
A school group may operate multiple School ERP subscriptions, while a coaching group may operate multiple Campus subscriptions. Each branch or centre remains in its own account for daily operations. Eligible subscriptions under the same customer can be reviewed through the separate CodePex Admin Console, subject to its declared access and information scope.
Where an owner operates both products, the central view should preserve what each metric means in its product. A school’s academic calendar and a coaching centre’s batch cycle are not automatically comparable. The console is a distinct product and does not convert School ERP or Campus into a cross-branch CRUD environment. Confirm eligible scope and access details with CodePex rather than assuming all fields are available everywhere.
07 / FICTIONAL EXAMPLES
Use scenarios to reveal the boundary before buying.
Imagine a group with two schools. Each school’s staff record admissions and fees in its own School ERP subscription. The owner reviews permitted subscription information centrally, then asks a school leader to explain a local change. The overview supports a conversation; it does not perform the school’s admission or fee correction for them.
Now imagine a coaching group with two centres, each using Campus, or an organisation that operates both a school and a coaching centre. The operating accounts remain distinct, and the owner’s oversight view should preserve product context. These examples illustrate a boundary, not a promise about a particular customer setup, data feed or custom report.
08 / QUESTIONS TO ASK
Evaluate what a central user can see, and what they cannot do.
Ask which subscriptions qualify, how authorised users are associated with the organisation, what information is available and how it is grouped. Request a demonstration of search, filters, permitted detail views and reports. Then test a question that could be misread across products: ask how the interface distinguishes product, location and reporting period, and what happens when a branch’s data is unavailable or uses a different definition.
Also ask explicitly about the limits: can an owner edit an operational record, create a learner, change a fee or trigger attendance follow-up from the oversight console? The current CodePex architecture says those operational actions stay in the relevant product account. Clarify the roles and process for handing an issue back to the branch team.
A FIELD GUIDE FOR YOUR TEAM
A multi-branch architecture checklist
Use this before procurement or rollout planning. It separates organisation-level oversight from the records and decisions each location owns.
| Lens | Question to ask | What to record |
|---|---|---|
| Organisation | Which subscriptions belong to the same customer identity? | Authorised account relationships and eligible subscription scope. |
| Branch operations | Where are daily learner, fee and academic records maintained? | Named local product account and responsible operating team. |
| Owner oversight | What information can authorised stakeholders review centrally? | Demonstrated views, report definitions and access boundaries. |
| Product context | How are School ERP and Campus data kept semantically distinct? | Product labels, applicable filters and known limits. |
| Handoffs | How does central review return an action to the branch? | Clear owner, local workflow and no implied central edits. |
CODEPEX IN CONTEXT
Useful guidance begins with clear scope.
CodePex uses separate School ERP or Campus subscriptions/accounts for branch-level operations. The separate Admin Console is the authorised oversight layer across eligible subscriptions associated with a customer. It supports visibility, permitted review and reporting—not creating, editing or deleting operational records or triggering branch workflows. Verify eligible information and account scope directly.
Product-specific statements are based on the current owner-controlled capability declaration. Ask CodePex to confirm any institution-specific configuration or unlisted requirement.