Role-Based Access Control: Lessons from Building HR and School Systems

Why access control is the heart of business software

When a system holds employee records, payroll or student results, the most important question is not what it can do but who is allowed to do it. A payroll screen that every staff member can open is a serious problem. A teacher who can edit another class's marks is a serious problem. We have built both an HR management platform and a school management portal, and in each the permission model shaped the whole design.

Start with roles, not individuals

Role-based access control (RBAC) assigns permissions to roles and then assigns users to roles. In the HR system, the main roles are administrator, employee and client. In the school portal, roles include super administrator, administrator, teacher, accountant, librarian, parent and student. Thinking in roles keeps the rules understandable and makes it easy to onboard a new person: you give them the right role instead of dozens of individual settings.

Enforce rules at more than one layer

A common mistake is to hide a button in the interface and assume the job is done. Anyone can call the underlying request directly. Real enforcement has to happen on the server and, ideally, in the database.

• Interface: show people only the menus and actions relevant to their role.
• Server: check the role on every request before running the action.
• Database: in the HR system we use row-level security in the database itself, so even a bug in the application cannot return another person's data.
• In the school portal we use middleware on each route group, so entire areas are closed to the wrong roles.

The same page can serve different people

In the HR system, pages such as attendance, payroll and documents are shared routes whose content changes with the role. An administrator sees everyone, an employee sees their own records and a client sees only what concerns their account. This avoids duplicating pages, but it means each page must be written carefully so that data is filtered at the source and not just in the display.

Field-level permissions

Sometimes roles are not detailed enough. An employee may be allowed to update their phone number but not their salary or job title. We support field-level permissions, which let administrators decide which parts of a profile employees may edit for themselves. These settings control the interface, while database rules remain the final protection.

Keep an audit trail

Whenever someone changes something sensitive, such as a role, a salary or a mark, the system should record who did it, what changed and when. Audit logs are invaluable when a question arises later, and the simple fact that actions are recorded discourages misuse.

Practical advice

• Write down the roles and what each may do before you build.
• Default to no access, then grant what is needed.
• Test with real accounts of each role, including attempts to reach pages directly.
• Handle account lifecycle: disabled users and former staff must lose access immediately.
• Review permissions regularly as the organisation changes.