Role and permission guide for school management, ERP, and SIS

Permissions are part of the workflow

A role is not useful because its name sounds familiar. It is useful when the school can explain what a person may view, create, edit, approve, publish, export, or administer in a specific situation. Those actions should be tested against the records and risks the role actually encounters.

Start with workflows rather than a list of job titles. A teacher entering attendance, a finance user reconciling a payment, an academic head publishing a result, and a parent viewing a receipt each require different boundaries.

Build a permissions matrix

Create rows for sensitive entities and columns for actions. Add the context that changes the decision, such as campus, class, subject, academic period, approval status, or relationship to a student.

• View: which fields and records are visible?
• Create: who can add a record or request?
• Edit: who can correct it and under what conditions?
• Approve: who verifies the change?
• Publish: when does another role or family see it?
• Export: which output is allowed and why?
• Administer: who changes the permission itself?

Test ordinary and exceptional scenarios

Test a normal workflow and then change one variable: a teacher moves class, a student changes campus, a guardian relationship is corrected, a staff member leaves, a result is unpublished, or a finance record needs reversal. The expected boundary should remain clear after each change.

Include negative tests. Try to access a record outside the role, edit an approved value, export a sensitive field, and view a family’s unrelated student. A permission model is not validated by showing only the happy path.

Record the expected result before the test and the actual result afterward. If the behavior differs, classify the issue as configuration, data, training, integration, or product boundary. The classification determines who can resolve it and whether the rollout should pause.

Review lifecycle and accountability

Assign an owner for granting, reviewing, changing, and removing access. Schedule reviews around staff changes, term transitions, campus moves, and new workflows. Record the reason for elevated access and its end date where appropriate.

School data governance guidance emphasizes access, security, quality, and lifecycle controls together. A permission that is correct on day one can become unsafe when a person’s role or the school’s process changes.

Include an escalation route for disagreements. If a teacher needs access to complete a time-sensitive task but the role would expose unrelated records, the owner should be able to approve a defined exception, record its duration, and review the result rather than sharing a broad account.

Review exports as carefully as on-screen access. A role may appear narrow in the product while a downloadable report includes fields the recipient does not need. Define the purpose, fields, recipient, retention, and approval for important exports.

Connect permissions to publishing

Saved, approved, and published values may be different states. Define who can move a record between them and what a family sees while a correction is pending. This is especially important for attendance, assessments, fees, documents, and communications.

Test the pending state with a real support owner before launch.

Use evidence in vendor evaluation

Ask vendors to demonstrate the matrix with representative sample data. Record native behavior, configuration, integration, manual workaround, roadmap, and unknown separately. Do not accept a general assurance of role-based access as proof of a particular school’s required boundary.

GOV.UK guidance recommends considering staff access control and security measures when procuring educational technology. The school’s data protection officer and legal advisers should review the actual processing and contract.