Role-Based Access Control: What Your System Actually Needs
Permissions are consistently underscoped and cause expensive rework later. Roles vs permissions, record-level access, audit trails, and admin impersonation.
Role-Based Access Control: What Your System Actually Needs
Permissions are one of the most consistently underscoped parts of a custom system brief. It's easy to say "admins can do everything, users can do less" early on, and expensive to retrofit proper access control once the system is already built around that assumption.
Roles vs permissions
A role is a label — "manager," "operator." A permission is a specific capability — "can approve refunds," "can edit stock levels." Systems that hard-code behaviour to role names get brittle fast: the moment you need a manager who can't approve refunds, or an operator who can, the role-based logic breaks. Modelling permissions separately from roles, and assigning permissions to roles, keeps the system flexible as your org structure changes.
Hierarchy
Does a senior manager automatically inherit everything a junior manager can do, or are permissions assigned independently at every level? Hierarchical inheritance is simpler to reason about but less flexible; independent assignment is more flexible but needs careful admin tooling so nobody accidentally gets more access than intended.
Record-level access
Role-level permissions answer "can this user edit stock records at all." Record-level access answers "can this user edit stock records for warehouse B specifically." Multi-location or multi-department businesses usually need the second, and it's a meaningfully bigger build than the first — worth deciding early rather than discovering the gap after launch.
Audit trails
Who changed what, and when. Beyond compliance, this is often the first thing anyone asks for the moment a number looks wrong — and if it wasn't built in from the start, it can't be reconstructed retroactively.
Admin impersonation
The ability for an admin to see the system exactly as a specific user sees it, to debug a reported issue without guessing. Small to build, disproportionately useful for support — and worth logging separately in the audit trail given the access it grants.
Common role structures by business type
| Business type | Typical role structure |
|---|---|
| Single-location operations team | Operator, supervisor, admin — role-level permissions, no record-level split needed |
| Multi-location retail or warehousing | Location-scoped operator and manager roles, plus a company-wide admin — record-level access by location |
| B2B platform with client accounts | Internal staff roles plus client-side roles scoped strictly to their own account's data |
This connects directly to our post on custom admin dashboards — permissions design is usually the hardest part of getting a dashboard right, not the interface itself.