A UX lesson from designing permissions in B2B SaaS
I’ve been working on permission and role management for a B2B AI product.
One thing that makes this tricky is that a user’s role doesn’t always tell you what they should be able to do.
For example, someone might manage a project without managing the entire workspace. They need control over their project’s settings and members, but that doesn’t necessarily mean they should have access to organization-wide settings.
This creates an interesting UX problem.
If permissions are too broad, users may have access to things they shouldn’t. But if they’re too restrictive, people end up asking an admin for help with routine tasks.
One approach I’ve been exploring is to separate workspace-level responsibilities from project-level responsibilities, rather than treating every admin as the same type of user.
The part I find most important is making those boundaries visible in the UI. Users shouldn’t have to discover what they can and can’t do by clicking around and getting permission errors.
For anyone building B2B products with multiple roles, how do you make permission boundaries understandable without turning the interface into a complicated access-control panel?
Replies
I used to handle this in the nineties. I built portals, for each manager type. I spent three years untangling an Active Directory deployment. People kept creating security groups just so someone could edit a single folder. It was a nightmare.
Put the scope beside the role wherever it appears so Project admin always names the project
For a blocked action show who can grant access and a request button that includes the project and action so users do not have to translate the permission model