# Role-Based Access Control Done Right At a 200-person company, I once found 47 custom roles in their platform. Nobody could explain what 30 of them did. Several employees had combinations of roles that effectively gave them admin access — by accident. One intern could approve purchase orders up to €50,000 because someone copied the wrong role template. RBAC that nobody understands is worse than no RBAC at all, because it creates a false sense of security. ## The Three RBAC Mistakes ### Mistake 1: Binary Roles (Admin / User) Small teams start here. It works at five users. At thirty users, every other request is "Can I be admin? I need to access the reports." So you make everyone admin, and RBAC becomes theater. ### Mistake 2: Permission Explosion The overreaction to Mistake 1. Create a permission for every possible action: read-documents, write-documents, delete-documents, share-documents, read-own-documents, read-department-documents... Multiply by every feature, and you have 500 permissions that nobody can manage. ### Mistake 3: One-Off Exceptions "Marketing needs access to the client portal but not the financial reports — except for Sarah who does the monthly revenue review." Exceptions pile up until the permission model is an undocumented mess that only the person who configured it understands. ## The Practical RBAC Model After implementing RBAC across multiple organizations, I've landed on a model with four layers: ### Layer 1: Preset Roles (3-6 roles) Define 3-6 standard roles that cover 90% of your organization. Name them clearly: - **Viewer:** Read access to non-sensitive data. For stakeholders who need visibility without edit capability. - **Contributor:** Read and write access to their own department's data. For team members doing daily work. - **Manager:** Contributor access plus approval workflows, reports, and team management within their department. - **Administrator:** Full platform access including user management, settings, and integrations. These roles should be understandable by non-technical people. If a role name needs explanation, rename it. ### Layer 2: Department Scoping Roles apply within a scope. A Manager in Marketing shouldn't automatically see Engineering's data. Scoping roles to departments or teams provides data isolation without creating dozens of role variants. This means "Marketing Manager" and "Engineering Manager" use the same role definition (Manager) with different scope (Marketing, Engineering). One role to maintain, multiple applications. ### Layer 3: Feature Toggles Some features should be available to specific roles regardless of department. Financial reporting might be available to all Managers. API access might be limited to Administrators and specific Contributors. Feature toggles attach to roles as add-ons, keeping the core role model simple while allowing targeted access to specialized features. ### Layer 4: Temporary Elevations For the inevitable "Sarah needs access to financial reports this quarter for the audit," use time-boxed permission elevations. Grant additional access with an automatic expiration date. No permanent exceptions, no forgotten elevated access. ## Implementation Principles ### Principle of Least Privilege Every user starts with the minimum access needed to do their job. Additional access is granted explicitly, not by default. This sounds obvious but is violated constantly — especially during onboarding when IT copies an existing user's permissions "just to get them started." ### Inheritance Over Assignment Instead of assigning permissions individually, users inherit permissions from their role. Change the role, and everyone with that role updates automatically. This prevents configuration drift where User A with the "Manager" role has different actual permissions than User B with the same role. ### Audit Everything Every permission grant, role change, and access decision should be logged. Not for surveillance — for accountability. When something goes wrong, "who had access to what, when" should be answerable from audit logs, not from interviews. ### Review Quarterly Access reviews aren't just a compliance checkbox. They're how you catch drift: the intern who still has their temporary admin access six months later, the contractor who left but whose account is still active, the team that expanded from 5 to 15 but still uses the same shared login. ## Common Patterns by Organization Size **Under 20 users:** Three roles (Viewer, Contributor, Administrator). No department scoping needed. Manual role assignment is fine. **20-100 users:** Four to five roles with department scoping. SSO-based role assignment (your directory groups map to platform roles). Quarterly access reviews. **100-500 users:** Five to six roles with department scoping and feature toggles. SCIM-based automatic provisioning. Monthly access reviews for sensitive roles. Temporary elevation workflows. ## Testing Your RBAC After configuring roles, test these scenarios: 1. **Can a Viewer edit anything?** They shouldn't be able to. 2. **Can a Contributor see another department's data?** Only if scoping allows it. 3. **Can a Manager approve their own requests?** Segregation of duties should prevent this. 4. **Can an Administrator be locked out by another Administrator?** There should be a break-glass procedure. 5. **What happens when a user has no role?** They should see nothing, not everything. ## The Human Side The best RBAC implementation fails if users work around it. "I can't access this report, so I'll ask David to screenshot it and email it to me" defeats the purpose entirely. To prevent workarounds, make the happy path easy. If people need access, the request process should take minutes, not days. If permissions are too restrictive, users game the system. If they're appropriate, users barely notice they exist. That's the goal of good RBAC: security that's invisible to the people doing their jobs correctly, and a clear barrier for everything else.