Who should see what? Role-based logins in a school office

One password on the office computer

In many school offices, the software, or the shared folder of spreadsheets, is opened with one login that everybody knows. The accountant uses it, the front desk uses it, and a teacher borrows it to look up a phone number. It is convenient until a fee balance changes and nobody can say who changed it, or a family's details are seen by someone who never needed them.

The real problem is responsibility, not secrecy

Roles are often discussed as a way to keep secrets. In a school office the bigger issue is responsibility. When five people share one login, every change belongs to nobody, and a record of "who changed what" is impossible. That record only exists when each person signs in as themselves.

Two more questions follow from that:

• What does each person need to see and do for their job, and what do they not need?
• Which decisions should need a second person: the ones that cost money, or change a published result?

Start from jobs, not people

Write down the jobs in your office before you write down names. The table below is a sensible starting point for most schools, and it mirrors the default role templates in Campus One.

People can hold more than one job, and the roles are a starting point. Campus One gives each school its own editable copy of the role templates, so the office can adjust them to how it really works.

Keep asking and approving apart

The decisions that matter most should need two people: one who asks and one who approves. Campus One's defaults follow that rule in three places:

• Fees. The accounts role records payments, but its default template cannot approve fee adjustments.
• Purchases. The store administrator can request a purchase but cannot approve it. In the demo school, purchase requests are routed for approval by value, and the person who raised a request cannot approve it.
• Question papers. Teachers can view a paper under review; only approvers can approve it.

Hiding a button is not a permission

Some software "removes" a feature by hiding its button. Anyone who finds the page's address, or reaches the function another way, can still use it. The safer rule is that every action checks permission on the server, every time.

In Campus One, every action passes the same checks, in order, before it runs: who you are; which school and campus you are working in; whether your role allows the action; whether the school has that product; and whether the input is valid. Only then does it run, and it is written to the audit record. Each login works inside an organisation, a campus and an academic year.

The same rule reaches the less obvious places:

• Search. A member whose role cannot read student records gets no student results, even by typing an exact phone number, because the permission check is part of the search itself.
• Recently viewed. Recent records are checked again when they are shown, so someone who loses access to fee records stops seeing them in their recent list.
• Separation between schools. Each school's rows are kept apart in the database itself, by a rule on every table, which is designed so that one school cannot see another school's records.

The evidence: what the demo shows

The Campus One demo has a made-up school with a login for each role: school owner, principal, head of administration, academic head, teacher, accounts manager, operations manager and admissions counsellor. A walkthrough can show the same student from two logins, for example a teacher's and an accountant's, so you can see what each role sees and what it does not.

Both plans include unlimited staff logins, so nobody has to share a password to keep the bill down. The price is set per school by the number of students, as the pricing page shows.

This describes how the product is built. It is not a certification, a compliance claim or legal advice.

The outcome: every change has a name

When each person signs in as themselves, the question "who changed this?" has an answer, approvals sit with the people who should give them, and sensitive records stay with the people who need them. Our guide to audit trails in a school office shows what that history looks like for marks, receipts and stock.

The takeaway

List the jobs in your office, write down what each one needs, separate asking from approving, and ask every vendor whether permissions are checked on the server. The Campus One page for principals, the office and accounts teams shows how each desk uses its login, and our checklist for choosing school software covers the rest of the decision. To see two roles side by side on the demo school, ask us for a walkthrough.