User Roles and Permissions: How to Design Them Well

A permission is one specific thing a person can do, like editing an invoice. A role is a named bundle of permissions, like "Accountant." You give people roles, and the roles carry the permissions. That is the whole idea behind role-based access control (RBAC), and getting it right early saves you painful rework later.

This guide is for business owners and founders in Canada and the US who are planning an app, a portal or an internal tool. We build these at Westcode, so we will keep it practical.

TL;DR

A permission is a single action on a single resource. A role is a bundle of permissions tied to a job function.
Give permissions to roles, and roles to users. Avoid one-off permissions for individuals.
Build roles around stable business functions, not job titles or screen menus.
Apply least privilege, and write down which roles must never be combined.
Review access on a schedule, and plan for temporary access with an end date.

What user roles and permissions are

The terms get mixed up, so let's pin them down.

A permission is the granular right to perform a specific action on a resource. A role is a collection of permissions that defines a job function or level of access, as Auth0's RBAC overview puts it. Apache Shiro's authorization guide describes permissions as the most atomic level of a security policy, and roles as a way to simplify managing permissions and users.

Here is a plain example for a property management app:

Role	Example permissions
Owner	View all properties, edit billing, invite and remove users
Property manager	Create work orders, message tenants, view assigned buildings
Bookkeeper	View and export invoices, no access to tenant messages
Tenant	View own lease, submit maintenance requests

Notice that each role matches a real job. Nobody is listed by name.

How role-based access control works

RBAC runs in three steps: define permissions, assign permissions to roles, and assign roles to users. When someone asks for a resource, the system checks whether their roles together include the permission they need. Auth0 describes the same three steps.

The model is not new. NIST says the general-purpose RBAC model was proposed in 1992 by Ferraiolo and Kuhn. It rests on three rules: a person must be assigned a role, the active role must be authorized for that person, and an action must be authorized through role membership.

Microsoft's authorization basics calls RBAC possibly the most common way to enforce authorization in applications. An administrator assigns roles, and the roles decide who reaches which resources and features.

Roles can inherit from each other

OWASP's Authorization Cheat Sheet notes that a user can hold several roles, a role can have many users, and roles can be hierarchical. A manager role might include everything a staff role can do, plus a few extras. Hierarchies cut repetition, but keep them shallow so you can still explain who can do what.

Roles only, or roles plus direct permissions?

Go through roles. In the RBAC model, as NIST explains, all access flows through roles, and users receive permissions only from the roles they hold or inherit. That is what separates RBAC from setups where permissions attach straight to people.

Why does this matter in practice?

Audits get easier. You answer "who can approve refunds?" by looking at one role.
Onboarding gets faster. A new hire gets a role, not a checklist.
Exits get safer. Removing a role removes everything it carried.

Direct permissions feel quick on day one. A year later nobody remembers why one person can delete records.

How to design roles that last

Start from the work, not the screens

IBM's RBAC implementation guide advises starting from business functions and workflows rather than application menus. It also suggests mixing top-down workflow analysis with a bottom-up look at the access people already have. That avoids roles that are too theoretical and roles shaped around odd exceptions.

In plain terms: sit down with the people who do the work. Ask what they do each week, what they must see and what they must never touch. Capturing that knowledge in a shared, validated format helps; a validation workflow for role design shows one way to get responsibilities written down and agreed before anyone builds.

Keep roles tied to stable functions

Oso's RBAC best practices recommend treating permissions as atomic units, roles as bundles, and basing roles on business functions that survive a change of job title. A title like "Growth Ninja" will vanish. "Marketing editor" will not.

Watch for role explosion

Role explosion happens when you create a role per person or per exception. One rule of thumb from Passwork's RBAC design article: a role should map to a function that three or more people perform. If it does not, it is probably an exception, not a role.

Do not hide behind one big "User" role

A single catch-all role that holds every permission a typical user might need is a common source of over-privilege, according to a RBAC design patterns write-up. Split it into the few jobs that real users actually do.

Start with three tiers

IBM notes that organizations often begin with three broad categories: administrators, specialists or expert users, and end users. For a first version of an app, that is a sound starting point. Split further only when a real workflow demands it.

Least privilege and separation of duties

Least privilege means each role gets only what the job needs. OWASP points out that this works in two directions. An accountant and a sales rep at the same level need different resources (horizontal). A head of sales needs more than the people reporting to them (vertical). Both are covered in the OWASP cheat sheet.

Separation of duties adds a second rule: some roles must not be combined. Passwork's author gives a clear example: the role that approves purchase orders should not also create vendor records. Write rules like this into your access policy, and build them into the app so it blocks the combination.

A few places this shows up in real businesses:

A dealer portal where dealers see only their own pricing and orders.
A real estate app where an agent sees their own listings, and a broker sees the whole office.
A home service business tool where a technician sees today's jobs, and the office sees invoices.

Test that permissions are enforced

A role chart on paper proves nothing. OWASP advises defining trust boundaries during design, listing the types of users, and writing tests that confirm the permissions you mapped are actually enforced. Do this for every release.

Simple tests that catch real bugs:

Log in as each role and try every action it should be allowed to do.
Log in as each role and try actions it should be blocked from, including by pasting a direct URL or calling the API.
Check that a user in one organization cannot reach another organization's records.

It also helps to keep a record of who granted, changed or removed access. An audit trail for permission changes makes reviews and incident questions far easier to answer.

Review access as the app grows

Roles drift. People change jobs, contractors finish, and exceptions pile up.

IBM recommends periodic access reviews with managers and app owners, focused on exceptions and outliers instead of rechecking every standard role. It also suggests automating role changes when people join, move or leave, and giving temporary access clear time limits and approvals.

A guide to RBAC with Active Directory groups adds a useful pattern: business-facing role groups nested into resource-facing permission groups. It also suggests quarterly recertification for privileged and sensitive roles.

If you use a cloud identity service, you may not need to build everything yourself. Microsoft's guide to implementing RBAC in apps lists three approaches on its identity platform: app roles, groups, or a custom data store. It names app roles as the preferred route because it is the easiest and has direct SDK support. AWS describes a layered design for consumer apps, with separate authentication and authorization layers, plus regular security reviews.

Our perspective

Most access problems we see are not technical. They start when nobody wrote down who does what.

So we start with a conversation, not a database table. We ask you to walk us through a normal week: who creates records, who approves, who only needs to look. Then we turn that into a short list of roles and test it with you before we build it. You stay involved from the idea through launch, and you can see why every permission exists.

We think roles should be boring and clear. Few roles, named for real jobs, with rules about what cannot be combined. That keeps dealer portals, membership areas and internal tools easy to grow, and easy to hand to the next person who has to manage them.

Loic

Plan your roles with us

If you are planning an app, a client portal or a dealer login, roles and permissions are worth settling before design starts. We work with startups, realtors, property managers, distributors and home service businesses across Canada and the US. We scope each project to your needs and keep you in the loop from concept to launch.

See how we approach custom app development.

FAQ

What is the difference between a role and a permission?

A permission is one allowed action, such as "export invoices." A role is a named set of permissions that matches a job, such as "Bookkeeper." You assign roles to people, and the roles carry the permissions.

What is RBAC in simple terms?

RBAC means access is granted by role, not person by person. You define permissions, group them into roles, then assign roles to users. When someone makes a request, the system checks whether their roles allow it.

How many roles should my app have?

Start with a few: an administrator, a role for the main working users, and an end user. Add a role only when a real job needs different access. A good test is whether several people perform that same function.

Can I give one user an extra permission outside their role?

It is possible, but it is how access gets messy. If the need is temporary, grant a time-limited role with an approval and an end date. If it keeps coming up, that is a sign you need a new role.

How often should we review permissions?

Review on a regular schedule, and also when people join, change jobs or leave. Sensitive and privileged roles deserve the closest look, and exceptions deserve more attention than standard roles.