How should permissions and role-based access work?
Permissions and role-based access decide what each user can see and do. In B2B software an administrator configures them, so the screens for managing permissions matter as much as their effect.
Access is one decision. Screen structure for each role is another.
Key facts
- Roles should be named after jobs users recognise.
- A blocked action needs a clear message and the name of who can allow it.
- Permission changes need their own record.
- Permissions control access; choose shared, adaptive or separate layouts according to the tasks each role performs.
- Enterprise buyers ask about roles and permissions during evaluation.
What it covers
- Roles and the actions each role may take
- The administrator’s screens for creating roles and assigning them
- What a user sees when an action is not allowed
- The history of permission changes
Who uses it
| Role | What they need |
|---|---|
| Administrator | Set up roles once, adjust them as the company changes, see the effect before saving |
| Everyday user | Know what they can do and whom to ask when something is blocked |
| Auditor or security reviewer | See who had which access, and when it changed |
| Enterprise buyer | Confirm during evaluation that the product can express their roles |
What makes it hard to design
Matrices grow. Permission matrices with hundreds of checkboxes and no grouping are hard to configure and harder to check.
Access and layout get mixed. Access decides what a user may do. The screen for each role is a separate design question. Hiding fields is insufficient when roles need different task sequences or ways of comparing records. A shared layout can work when the underlying tasks are similar.
Silent failures. Actions that fail without a message when access is missing look like bugs.
Roles are set up during onboarding and touched again months later. The screens need to explain their own effect, because the administrator will not remember the setup.
Trade-offs
- Fine-grained permissions can express any customer’s organisation, and setup takes longer as a result. A short list of predefined roles is quicker to set up and leaves some customers without the role they need.
Common mistakes
- Relying only on hidden fields when roles need different workflows
- Permission matrices with hundreds of checkboxes and no grouping
- Actions that fail without a message when access is missing
- Role names taken from the system’s internal structure instead of jobs