Role-based access control assigns permissions to roles rather than to people, so access follows a job rather than an individual. It is the right default for most business software. It stops being sufficient when permissions depend on the record rather than the role, when a manager may see their own team but not another, or a user may edit a document only while it is in draft.
This guide covers how to design roles that survive contact with a real organisation, when to add attribute-based rules, and how to avoid the retrofit that touches every screen.
Key takeaways
- Model permissions before the first screen: Retrofitting access control is among the most expensive late changes in software.
- Roles come from job functions, not from the org chart: Titles change far more often than what people actually do.
- Most real systems are hybrid: Roles for what you can do, attributes for which records you can do it to.
- Enforce below the query: Application-level checks fail the day someone forgets one.
Design roles from what people do
Start by listing tasks rather than titles. For each task, name who performs it, what data it needs, and what it changes. Roles emerge from clusters of tasks that always travel together.
Building roles from the organisation chart produces a permission model that breaks at the first reorganisation. Building from job functions produces one that survives it, because the work stays the same even when the reporting line moves.
Keep the number small. Five to nine roles covers most business systems. Beyond about a dozen, nobody can say what a role grants, administrators start assigning several to one person to get a result, and the model stops describing reality.
Cover the four elements
| Element | Question it answers |
|---|---|
| Roles | What job is this person doing |
| Permissions | Which actions that job may perform |
| Record scope | Which records those actions apply to |
| Audit | Who did what, when, and under which permission |
Record scope is the element most often missed at design time and the one that causes the expensive rework. "Can view orders" is a permission; "can view orders belonging to their own branch" is a permission plus a scope, and the two need different machinery.
Test the model against awkward real cases
Every organisation has people who do not fit a clean role. Test the design against yours before implementation:
- A manager who is also an approver on their own team's requests
- A contractor with time-limited access to one project
- A support agent acting on behalf of a customer
- Someone covering a colleague's leave for two weeks
- A regional manager who sees three branches but not a fourth
- An auditor with read access to everything and write access to nothing
If the model cannot express these without inventing a role per person, it is not finished. Delegation and temporary elevation in particular are almost always needed and almost never specified.
Add attributes when the record decides
Pure roles answer "what can this person do." Many systems also need "to which records," which depends on attributes of the user and the record: branch, ownership, project membership, document status.
The practical pattern is hybrid: roles for actions, attributes for scope. "Editors may update articles" is the role; "only articles they own, and only while in draft" is the attribute rule. Keeping the two separate keeps the model readable, which matters because a permission model nobody understands gets bypassed with over-broad grants.
Enforce it below the application
Correctness cannot depend on every query remembering to filter. Push enforcement down: row-level security in the database, a scope bound to the session, or a data-access layer that refuses an unscoped query.
Then write tests that deliberately attempt unauthorised access. A suite that only covers permitted actions will pass on the day a check is missing.
Pay particular attention to the paths outside the normal request flow: background jobs, exports, reports, admin tooling and integrations. These sit outside the user session where permissions usually live, and they are where access leaks are found.
Build these in from the start
Least privilege by default. New roles start with nothing and gain what the job requires. Starting from a copy of an existing role is how permissions spread.
Act-on-behalf-of, recorded. Support teams need it. Retrofitted, it usually ends up unauditable.
Time-bounded access. Contractor and cover arrangements should expire automatically rather than relying on someone remembering.
Full audit trail. Who did what, when, and under which permission, visible on the record rather than only in a log file. This is what lets you grant broader permissions safely, which makes people faster.
Access review. A periodic report of who holds what, for an owner to confirm. Permissions accumulate; nothing removes them unless someone looks.
Retrofit is expensive, so do not
Adding access control to a system that assumed every user could see everything forces rework across every screen, every query and every report. It is one of the most expensive late changes available, and it is entirely avoidable by spending an afternoon on the model early.
Decide at design time whether permissions are role-based, attribute-based or hierarchical, and whether one person can hold several roles. Those three answers shape the data model, and changing them later means changing everything built on it.
Where compliance meets design
Under GDPR and Turkish data protection law, access to personal data should be limited to those who need it, and you should be able to demonstrate that limitation. An access model with a clear scope and a review process is a large part of that evidence.
For regulated work, health, financial, public sector, expect to show not only that access was controlled but that it was reviewed. Audit logging and periodic access review stop being good practice and become the thing you are asked to produce.
Related guides
- The question this one leaves open is answered in AI Workflow Automation: Use Cases, Risks, and Roadmap.
- Before committing to any of it, read Admin Dashboard Development: Features, Architecture, and Cost Drivers.
When the architecture questions in Role-Based Access Control: Roles, Permissions, and Examples need answering once, properly, Discuss Your Platform Foundation.
Ali Boran Gazel