Role-Based Access Control (RBAC)

Why it matters

Managing permissions person-by-person collapses as a team grows: access accumulates, nobody remembers why, and offboarding leaves ghosts with live credentials. RBAC matters because it makes access reviewable: you audit a handful of roles instead of every individual, and revoking a person is one clean operation.

How it works

You define roles that mirror real responsibilities, attach specific permissions to each role (view vouchers, approve up to a limit, export reports), then assign users to roles. Systems enforce the mapping at every request. Good implementations also support tiered approvals, so a role can act only within its limit and must escalate beyond it.

A real-world example

In a dealership expense system, a branch cashier can create vouchers, the branch manager can approve up to a set amount, the group finance head approves above it, and only the owner can delete anything. When a cashier changes branches, one role reassignment updates every permission at once.

Common mistakes

• ✗ Creating one 'admin' role that half the company ends up holding
• ✗ Cloning roles per person, which recreates individual permissions with extra steps
• ✗ Never reviewing role membership, so leavers and role-changers keep old access
• ✗ Forgetting deletion rights: if everyone can delete records, the audit trail is decorative

Best practices

• ✓ Mirror the org chart honestly: roles should match how responsibility actually flows
• ✓ Reserve destructive permissions (delete, export-all, config) for the narrowest role
• ✓ Review role assignments quarterly and on every exit
• ✓ Pair RBAC with audit logging so every permitted action is still attributable

Frequently asked questions