How Do You Design Roles and Permissions Without Confusing Everyone?

Why do permissions confuse almost everyone?

Because most permission systems are designed from the database outward. Each new feature adds a checkbox, the checkboxes get grouped into roles, and eventually nobody can predict what a role actually allows. The admin is guessing, and guessing about access is how mistakes happen.

Permissions are one of the few interface problems where being slightly wrong is expensive in both directions. Too loose and someone sees a salary they should not. Too tight and half the team cannot do their job, so they find a way around you.

Here is the framework we use when designing this, which is mostly about making the system predictable rather than making it powerful.

What is the first decision to make?

Decide whether your product is role driven or object driven, and commit. Role driven means access follows the person: an editor is an editor everywhere. Object driven means access follows the thing: this person can edit this document and nothing else.

Most products need a bit of both, and the failure mode is drifting between them without deciding. You end up with a workspace role and a project role and a document role, three sources of truth, and no interface that can honestly tell someone what they can do.

Pick the one that matches how your customers actually organise work. If they think in teams, go role driven and treat object level sharing as an exception. If they think in projects with outside collaborators, go object driven and keep roles thin.

How many roles should you have?

Three to five for most products, and you should be able to describe each in one sentence without using the word or. If a role needs a paragraph to explain, it is two roles that have been welded together.

The common set works because it maps to how people already think. Someone who runs the account, someone who does the work, someone who reviews or approves, and someone who can only look. Adding a fifth needs a real justification, because every extra role multiplies the combinations an admin has to reason about.

Resist the request for fully custom roles until you genuinely cannot avoid it. Custom roles sound like flexibility and arrive as support load, because now every customer has a unique configuration and nobody on your team can reproduce their bug. Our notes on settings page UX cover the same restraint applied to configuration generally.

How do you explain a role to the person choosing it?

Show consequences, not capabilities. An admin inviting someone does not want a list of 23 permissions. They want to know whether this person will be able to see billing, delete things, or invite others. Those are the three questions people actually have.

So write the role description in terms of the scary stuff. Can manage billing and remove members. Can create and edit content but cannot delete the workspace. Can view everything, change nothing. That is a sentence an admin can make a decision from.

Then show the full permission detail behind a link for the minority who want it. Most people never open it, and the ones who do are usually in a security review, where completeness matters more than clarity.

What should happen when someone lacks permission?

Tell them plainly, say who can help, and never pretend the thing does not exist. Hiding a feature entirely feels tidy and creates a specific kind of confusion where a user is following a colleague's instructions and the button they were told to click is not there.

The better pattern is to show the action, disable it, and explain why in one line. You need admin access to change billing, and then the name of an admin they can ask. That turns a dead end into a next step.

There is a genuine exception. If the existence of the thing is itself confidential, hide it. A junior employee should not learn that a Layoffs Q4 folder exists by being told they cannot open it. Decide which of your objects fall into that category deliberately rather than by default.

How do you handle the admin who wants everything?

Give them visibility instead of universal access, and make the difference explicit. Most admins asking for access to everything actually want to know what is happening, not to read every document. Those are different needs and only one of them requires access.

An audit log satisfies the real request far better than a master key. Who changed what, when, and from where. It also protects the admin, because the alternative is a role that makes them responsible for everything they could theoretically have seen.

Where an override genuinely is needed, make it a deliberate act rather than a standing state. Elevate for a reason, log the reason, and expire it. That is a normal pattern in security tooling and it is underused in ordinary business software.

What does shadow tooling tell you about your design?

That your permissions are too tight somewhere, or too slow. When people cannot do their job inside the system they leave it, and the data on this is getting hard to ignore.

Verizon's 2026 Data Breach Investigations Report, announced on 19 May 2026, found that 45 percent of employees now use unapproved AI tools, up from 15 percent previously. That is not a story about AI. It is a story about people routing around the sanctioned path when the sanctioned path is inconvenient.

The same report found that 48 percent of all breaches now involve third parties, with third party involvement up 60 percent. Every workaround your permission design creates tends to end up as data sitting somewhere you did not choose. Designing access that people can live with is a security measure, not a convenience.

How do you let people undo a mistake?

Assume every permission change will eventually be wrong and design for the correction. The two cases that matter are granting too much and removing too much, and they need different handling.

For over granting, an audit trail plus the ability to see current access at a glance is usually enough. An admin needs one screen that answers who can see this, sorted by risk, without clicking into every member.

For over removing, the recovery has to be fast, because a person is blocked right now. A request access flow that notifies an admin in the tool they actually use turns a support ticket into a thirty second approval. Our piece on notification design covers getting those messages to the right person without becoming noise.

How do you keep this usable as the product grows?

Add permissions to existing roles rather than adding roles, and write down the rule for where a new capability lands before you build it. Every feature team will otherwise invent its own answer, and after two years the model is incoherent.

A simple test helps here. When a new feature ships, can you place it in the existing roles without a discussion longer than five minutes? If not, either the feature is in the wrong place or your roles are already too vague.

Review the whole model once a year against real customer accounts. Look at which roles are actually assigned. You will usually find one role that nobody uses and one that everybody uses because it was the only one that worked. Both are design feedback.

What about the security side of this?

Least privilege is the right default, and it only works if the path to more privilege is easy. A system where getting the access you need takes two days does not produce careful users. It produces shared logins.

It is worth keeping the wider threat picture in view when you are making these trade offs. The 2026 DBIR reported that 31 percent of all breaches start with vulnerability exploitation, so permissions are one layer among several rather than the whole defence. Designing them well reduces blast radius rather than preventing incidents.

That framing helps in internal arguments. Permissions are about limiting how much damage any single mistake can do. Judged that way, the goal is a model people understand, not a model that is theoretically airtight and practically ignored.

What would we design first?

Write the three to five role sentences before designing any screen. Then design the invite flow, because that is where an admin makes the decision, and it is the screen that determines whether the whole model gets used correctly.

After that, build the who can see this view. It is the screen admins return to, it is the one auditors ask for, and it is the fastest way to find out whether your model is comprehensible. If that screen is hard to design, the model underneath is too complicated.

If you are designing an access model for a product and want a second opinion before it hardens, we are happy to walk through it. You can find us at phoenix.studio.