Accounts and permissions are the foundation that determines who can see what and who can edit what. For a system holding data on many educational institutions and serving several different user groups, this is the part that determines data integrity.
This guide describes the roles, their corresponding permissions, and the management process when staff change.
Underlying principle: minimum necessary access
The entire permission structure is built on a single principle: each person receives only the permissions their job requires, no more.
This principle sounds obvious but is often violated for convenience. Granting broad access to everyone avoids having to process requests, but the consequence is that it becomes impossible to determine who changed what, and a small mistake can spread across the entire record.
The practical result of this principle is that most users only have view access. Edit access is granted narrowly and always tied to a specific scope.
Four main roles
School profile administrator role. Belongs to the school, the owner of information about itself. This role can edit every item in its own school’s profile, submit update requests, and view change history. It has no access to other schools’ profiles.
Editor role. Belongs to the platform’s operations team. Can cross-check information against sources, record verification results, and update the verification date. Cannot unilaterally change content the school has already confirmed, only propose changes.
Enrolment partner role. Can view the entire published profile, download documents, and submit reports when information is found not to match reality. Has no permission to edit any content.
Reader role. Applicants, parents, and the general public. Can view the publicly published part of the profile, no account required.
Why a school cannot edit another school’s profile
This is a reasonable question, and the answer relates to the neutrality of the whole system.
If one school could influence another school’s profile, even just by having its suggestions prioritized, the data would lose its objectivity. Readers would not know whether they were looking at information about a school or information supplied by that school’s competitor.
For that reason the boundary is set firmly: each school has full authority over its own profile, no authority whatsoever over any other profile, including the right to view non-public parts.
If a school finds incorrect information in another school’s profile, the handling mechanism is the same as for any user: submit a report, and the editorial team verifies it against the source.
Accounts and permissions when staff change
This is a part that is often overlooked and also the source of most data security issues.
When someone new joins. Create a separate account for that person, do not reuse an existing shared account. A shared account makes it impossible to determine who did what.
When someone changes position. Review their permissions to match the new role. Old permissions do not automatically fit a new role.
When someone leaves. Revoke access the same day, do not wait for the periodic review. This takes only a few minutes but is often forgotten.
Periodic review. At least once a year, the school reviews the list of everyone who currently has access to its profile. This list is usually longer than expected.
A person should be designated on the school’s side to be responsible for account management. Without someone responsible, revoking access simply will not happen.
Email address used for registration
A small detail with large consequences: accounts should be tied to an email address under the school’s own domain, not a personal address.
The reason is very practical. When the person responsible leaves, a personal address goes with them, while the school’s address remains the school’s. All notifications, correspondence history, and account recovery ability are tied to the registered address.
For the school profile administrator role, there should be at least two accounts belonging to two different people. A single account creates a single point of failure: if that person is out for an extended period, the school loses the ability to update its own profile.
Change history
Every action that changes profile content is logged along with the time and the account that performed it.
This serves three purposes. It allows looking back at what the profile displayed at a given point in the past, useful in case of a dispute over information previously provided. It helps trace the source when an error is found. And it creates clear accountability for every action.
A school can view the complete change history of its own profile. This right comes with the administrator role and requires no separate request.
What data is not shown publicly
Not all information in the system is published externally.
The public section includes information useful for research and comparison: identification, programmes, costs, support, along with the source and verification date.
The section visible only to users with an account includes certain detailed documents the school wants to restrict in scope.
The hidden section includes internal contact information, working notes, and correspondence history between the school and the editorial team.
A school has the right to request moving an item from public to restricted, or the reverse, according to its own disclosure policy.
For content related to degree recognition that readers may need, the framework of The United Nations Educational, Scientific and Cultural Organization (UNESCO) is linked directly rather than being paraphrased.
When a school has multiple campuses or multiple units
For schools with multiple training campuses or faculties that operate relatively independently, permission management needs an additional layer.
The sensible approach is to grant permissions by content scope rather than by rank. The person in charge of a faculty can edit the information for programmes belonging to that faculty, but cannot edit the school’s overall identification section or the cost section managed by the finance office.
Above all this there still needs to be one school-level administrator account, with authority over the entire profile and ultimate responsibility for consistency.
This approach solves a real problem many schools face: if all edit permissions are concentrated in one person, that person becomes a bottleneck and the profile is updated slowly. If permissions are fully dispersed, parts of the profile will contradict each other because each unit uses its own figures.
The point to preserve is that no matter how permissions are structured, every change is still logged with the account that made it, so the source of every figure can be traced later.
Three common mistakes
Using one shared account for the whole department. Convenient in the short term but completely erases traceability, and when an issue occurs it is impossible to determine who did what.
Granting administrator access to too many people. The principle is that only people who genuinely need to edit the profile need this permission. Someone who only needs to look things up only needs view access.
Not revoking access when someone leaves. This is the most common and also the most serious error. Revoking access should be built into the school’s formal handover process.
When placing data governance standards in the broader context of the education sector, the policy reports of the Organisation for Economic Co-operation and Development (OECD) provide a reference baseline.
Summary
Accounts and permissions on the platform are built on the principle of minimum necessary access, with four roles having clear boundaries, in which each school has full authority over its own profile and no authority over any other profile.
The most important part in practice is not the permission design, but the discipline of account management when staff change.
Next Steps
Draw up a list of everyone on your school’s side who currently has access to the school’s profile, and cross-check it against the current staff list.
If any name no longer works at the school, that is something to handle today.
