A permission problem that isn’t really about permissions

One thing that gets tricky when designing B2B software is explaining permissions without making users learn the entire permission system.

Take a workspace with two roles: Workspace Admin and Project Admin.

The names seem clear enough. But what happens when a Project Admin tries to manage something outside their project?

A simple “You don’t have permission” message is technically correct. It just doesn’t help much.

I’d rather show which project the restriction applies to, what action is blocked, and who can grant access.

There’s also a small detail I think matters: showing the scope next to the role name. “Project Admin” means a lot less than “Project Admin · Project A.”

The interesting part is that none of this changes the permission model itself. It just makes the existing rules easier to understand.

Sometimes the problem isn’t that users need more permissions. They just need to understand the ones they already have.