How to design roles and permissions in B2B software

Why permissions are a design problem

Permissions often get treated as a back-end concern: engineering builds a role model, and design adds a settings page at the end. Then users start hitting greyed-out buttons with no explanation, admins can’t work out why a colleague can’t see a report, and support picks up the pieces.

In practice, permissions decide what each person’s product looks like. Two people with different roles are effectively using two different products. That makes the role model one of the most important design decisions in any B2B tool.

Start from jobs, not capabilities

The fastest way to build a confusing role model is to start with a spreadsheet of every capability and tick boxes. You end up with dozens of combinations nobody can reason about.

Start instead with the jobs people do. On a supervision platform for a global investment bank, the important distinction wasn’t “read” versus “write”. It was between a reviewer handling their own alerts, a supervisor overseeing a team’s workload, and the actions each of them was allowed to take on individual or grouped alerts. Those jobs became personal and team views, and the permissions followed from them.

A simple way to start:

1. List the main roles in plain language, as your customers would describe them.
2. For each role, write the three to five tasks they come to the product to do.
3. Map what they need to see and do for each task.
4. Only then group the capabilities into roles.

Explain what people can’t do

A disabled button with no explanation is one of the most common frustrations in B2B software. People don’t know if it’s a bug, a missing setting or a permission issue, so they raise a ticket.

When an action isn’t available, say why in plain words and point to a way forward. “Only account admins can invite colleagues. Your admin is Priya Shah.” is far better than a greyed-out button. Sometimes hiding the action entirely is right, especially if the person will never need it. But if they reasonably expect to see it, hiding it just creates a different kind of confusion.

Design for delegation and change

People go on holiday, move teams, leave the company and join halfway through a project. Your permission model needs to handle all of it without breaking work in progress.

Questions worth answering early:

• Can someone delegate their approvals temporarily? Who can see that they have?
• What happens to items assigned to a person who’s removed?
• Can a role change take effect immediately without losing someone’s drafts?
• Is there always at least one person who can fix access problems?

These aren’t edge cases. In large organisations they happen every week.

Make access visible to admins

Admins need to answer a simple question quickly: what can this person do, and why? A clear view of each person’s role, the groups they belong to and any exceptions saves hours of guesswork. A plain history of access changes helps too, especially in regulated industries where you’ll be asked who changed what, and when.

Keep role names human. “Approver (up to £10k)” tells an admin far more than “Role_L2_FIN”.

Test with the awkward combinations

When you prototype or test, don’t just log in as the most powerful user. Try the person with the least access who still needs to do the job. Try someone who’s halfway through a role change. That’s where the confusing moments live.

If your product has grown a permission model that nobody fully understands, a UX Audit of one key workflow will show where it’s hurting users. To design a clearer model from the ground up, Complex Workflow Design includes permission states for every screen in the journey.