EDUCATION MANAGEMENT · OWNER OVERSIGHT
CodePex Admin Console: A Practical Guide to Owner-Level Oversight Across Subscriptions
Understand how owner-level visibility can support subscription review across eligible institutions while keeping each institution’s day-to-day operations separate.
THE SHORT ANSWER
Owner oversight and institution operations are separate responsibilities. School ERP or Campus teams work within their own subscriptions; the Admin Console provides authorised visibility across eligible subscriptions associated with a customer. Use it to review permitted information and reporting, not to create, edit or delete branch operational records or trigger local workflows.
01 / TWO RESPONSIBILITIES
Separate the work happening inside a branch from the owner’s review.
A group with several institutions may need both local operating systems and a way for an authorised owner to understand the wider portfolio. These are related needs, but they are not the same workspace. A school team manages school records in its School ERP subscription; a coaching team manages its centre in Campus.
The Admin Console is a separate oversight layer. It should not be evaluated as a shared institution account or as a way for a central user to perform branch admissions, fee corrections, attendance or other operational work.
02 / SUBSCRIPTION SCOPE
Ask which subscriptions qualify and how they are associated.
Before relying on a group view, establish which subscriptions are eligible, how the customer relationship is represented and who can approve an association. Distinguish a location, a legal institution and a product subscription; those terms may not mean the same thing in every organisation.
Ask how a new branch is included, what happens when a subscription changes and how ownership is verified. Do not assume that every account sharing a name or email belongs to the same organisation.
03 / INFORMATION BOUNDARY
Verify exactly what the owner can see before making reporting decisions.
Request a demonstration of the available subscription-level information, permitted details and reports. Ask how product, location and reporting period are identified. A central total without its scope can encourage an inaccurate comparison.
Not every learner, staff or financial detail necessarily belongs in a cross-subscription view. Confirm the information boundary and the role that can see it, especially where School ERP and Campus use different operating contexts.
04 / REVIEW, NOT CONTROL
Use central visibility to ask better questions of local leaders.
An owner can spot a question that merits follow-up: a subscription needs attention, a report differs from expectation or an institution may need support. The next step is a conversation with the accountable local leader, who can verify the source and act within the institution’s own system.
Do not infer that the Console can change local records or trigger a workflow. This boundary protects accountability: the central view can support oversight, while the institution’s authorised team remains responsible for operations.
05 / COMPARISON & CONTEXT
Compare only like information and explain differences before acting.
A school and a coaching centre may use different measures, calendars and workflows. Even two schools can have different enrolment periods or reporting definitions. Confirm the date range, data freshness and metric definition before comparing values across subscriptions.
Treat a difference as a prompt to investigate, not proof of poor performance. Ask the local owner what changed, check the underlying report and document any limitation that makes the comparison incomplete.
06 / ACCESS & GOVERNANCE
Define who may review the portfolio and how that access changes.
Identify owner, finance and other roles that need central visibility and the decisions each role can make. Keep access proportionate, review it when responsibilities change and understand how an authorised user is removed. Confirm the actual product controls and history rather than assuming a particular access workflow.
A sound oversight model combines clearly separated subscriptions, named local operators, restricted owner access and a process for resolving questions. It improves visibility without turning the central layer into an unbounded operational account.
A FIELD GUIDE FOR YOUR TEAM
An owner-oversight evaluation guide
Use these questions when deciding whether a central view across separate school or coaching subscriptions fits your organisation.
| Lens | Question to ask | What to record |
|---|---|---|
| TWO RESPONSIBILITIES | Separate the work happening inside a branch from the owner’s review. | A clear map of local operating accounts and the separate oversight role. |
| SUBSCRIPTION SCOPE | Ask which subscriptions qualify and how they are associated. | An owner-approved list of eligible subscriptions and association rules. |
| INFORMATION BOUNDARY | Verify exactly what the owner can see before making reporting decisions. | A written information scope with examples of permitted and excluded data. |
| REVIEW, NOT CONTROL | Use central visibility to ask better questions of local leaders. | A review-to-local-owner process that preserves operational responsibility. |
| COMPARISON & CONTEXT | Compare only like information and explain differences before acting. | A comparable measure, stated limitations and a local explanation. |
| ACCESS & GOVERNANCE | Define who may review the portfolio and how that access changes. | A role model with access review, local accountability and escalation. |
CODEPEX IN CONTEXT
Useful guidance begins with clear scope.
The Admin Console is a distinct owner-level oversight layer across eligible subscriptions. It supports authorised visibility and review, not operational CRUD or workflow triggering in School ERP or Campus. Verify eligible subscriptions, information scope, roles and reports directly; do not assume every operational data field is centrally visible.
Product-specific statements are based on the current owner-controlled capability declaration. Ask CodePex to confirm any institution-specific configuration or unlisted requirement.