By Mehdi HassanRoles and permissions are where SaaS products quietly get complicated. The first version is single-player, then customers ask for teammates, then for viewers who can't edit, then for admins who can't see billing. Each request gets bolted on, and a year later nobody can explain who can do what. This guide covers the model and the interface together, because one can't be designed well without the other. It's part of our guide to SaaS product design.
How do you approach roles and permissions UX in a SaaS product?
You design roles and permissions by defining the data model first, then the roles, then the interface. Decide what a workspace is and who owns data, name a small set of roles by what they can do, and only then design the switcher, invite flow, role table and access states.
Define the tenant
Decide what the top-level container is: a personal account, a workspace or an organisation with several workspaces. This is the hardest decision to change later.
List the actions
Write every meaningful action users can take: view, create, edit, delete, invite, manage billing, export. Group them by object.
Name a few roles
Bundle actions into three or four roles, such as Owner, Admin, Member and Viewer. Name them by what users can do, not by job title.
Decide the exceptions
Will some objects, like a private project, have their own access list? Add this only if customers need it.
Design the surfaces
Switcher, invite flow, members page, role table, access-denied and request-access states.
This sequence matches step two of our guide on how to design a SaaS app from scratch, where the object model is drawn. Mark early which objects belong to a person and which to a team.
Which permission model should a SaaS app use?
Most SaaS apps should use role-based access control (RBAC) with a small set of fixed roles at the workspace level, adding object-level sharing only where the product needs it. Fully custom roles and attribute-based rules suit large enterprise products, not early ones.
Model | How it works | Good for | UX cost |
|---|---|---|---|
Fixed roles (RBAC) | Each member has one role per workspace | Most B2B SaaS | Low: easy to explain |
Roles plus object sharing | Workspace roles, plus per-project access lists | Docs, design, project tools | Medium: two places to check access |
Custom roles | Admins build roles from permission lists | Enterprise plans | High: needs a builder UI |
Attribute-based rules | Access depends on attributes, such as region or team | Regulated or very large orgs | Very high: hard to explain |
Every step down the table makes the interface harder to understand, so move down only when customers are asking and paying for it. Custom roles are often a natural feature for a higher plan, so plan this work alongside your pricing.
How should a workspace switcher work?
A workspace switcher should sit in the global layer, usually at the top of the sidebar, show the current workspace name and avatar clearly, and let users switch, create or join a workspace from one menu. Switching should change the whole context, including URLs, so nobody edits the wrong workspace by accident.
- Make the current workspace obvious. Name and avatar, always visible, ideally with a distinct color per workspace.
- Keep URLs scoped. Include the workspace in the URL so shared links open in the right context.
- Handle links to other workspaces. If a user opens a link from a workspace they're in, switch automatically and say so.
- Show role per workspace. Users often have different roles in different workspaces; show theirs in the menu.
Where the switcher sits relative to the rest of the navigation is covered in SaaS information architecture.
How do you design a team invite flow?
Design a team invite flow so the inviter chooses the role at the moment of inviting, can invite several people at once and sees pending invites afterwards. The invitee should land in the right workspace with a short explanation of what they can do.
Moment | What to design | Common gap |
|---|---|---|
Invite form | Multiple emails, role picker with plain descriptions | Role defaults silently to Admin |
Plan check | Show if the invite adds a paid seat, before sending | Surprise charge on the next invoice |
Pending invites | List with resend and revoke | Invites expire with no visibility |
Invite email | Who invited them, to which workspace, with what role | Generic "You've been invited" |
First login | Lands in the inviting workspace with a role summary | Lands on an empty personal account |
How should a role table read?
A role table should read as plain-language capabilities grouped by area, so an admin can decide whom to give which role in seconds. Avoid listing raw permission keys such as projects.write. Users think in tasks, like "Can invite people", not in system scopes.
Capability | Owner | Admin | Member | Viewer |
|---|---|---|---|---|
View projects and reports | Yes | Yes | Yes | Yes |
Create and edit projects | Yes | Yes | Yes | No |
Invite and remove people | Yes | Yes | No | No |
Manage billing and plan | Yes | No | No | No |
Delete the workspace | Yes | No | No | No |
Put this table in the members page and link to it from the role picker. The words matter as much as the grid; our guide to UX writing for SaaS has examples of role descriptions that explain consequences.
How do you design access-denied states?
Design access-denied states to explain three things: what the user tried to do, why they can't, and who can help. Then give them a way forward, such as a request-access button or the name of an admin. A blank page or a generic 403 is a dead end.
Situation | Better pattern |
|---|---|
Viewer clicks Edit | Disable with a tooltip: Viewers can't edit. Ask an admin for Member access |
Link to a private project | Page explaining it's private, with Request access to the project owner |
Link to another workspace | Explain which workspace it belongs to and offer to switch or request to join |
Hidden admin section | Hide from the nav for non-admins rather than showing a locked page |
Choose deliberately between hiding and disabling. Hide controls the user will never be able to use in their role. Disable, with an explanation, controls they could use if they asked. That keeps the interface clean without leaving people confused.
For example, suppose an agency tool lets clients into a workspace
For example, suppose an agency project tool wants clients to see progress on their own project. A workspace-level Viewer role would let clients see every client's project, which is wrong. So the model gains object-level sharing: guests who belong to a single project. The interface then needs a Guest badge, a project-level members list, an invite option on the project itself and an access-denied state for guests who follow a link to another project. Deciding this in the model first keeps every one of those screens consistent.
This is a hypothetical example to show how the model drives the UI, not a real client.
Where do roles and permissions live in settings?
Roles and permissions live in workspace settings, separate from personal account settings, usually on a Members or People page with the role table, pending invites and an audit trail for larger plans. Billing should be its own area, visible only to roles that can change it.
Our guide to SaaS settings page design covers how to split personal and workspace settings, and B2B SaaS UX principles covers the wider rules on states and reversibility. If you're retrofitting teams into a product that started single-player, the redesign usually touches navigation, settings, billing and every list view. That's a good fit for a fixed-scope sprint: our $3,000 brand and design sprint includes 10 website or product explorations.
