How to Design Roles and Permissions in B2B Systems

Permissions are not simply hidden menus. Even without a visible entry point, users may reach a resource through a link, API, or old page. The interface explains what users can see and why an action is unavailable; the server must enforce authorization on every request.

Permissions are not simply hidden menus. Even without a visible entry point, users may reach a resource through a link, API, or old page. The interface explains what users can see and why an action is unavailable; the server must enforce authorization on every request.

01 Separate Four Permission Layers

Permission problems in complex B2B systems often arise because one “role” field carries too many meanings. Separate permissions into four layers:

Many products implement only the first layer. The menu looks clean, yet a shared link reveals unauthorized data; or a visible button returns only a vague “No permission” after the user clicks.

02 RBAC Is a Starting Point, Not Always the Finish Line

The basic RBAC relationship is that users receive roles and roles receive permissions. It fits organizations with stable jobs and generalizable rules, such as sales representative, sales manager, finance, and system administrator.

When permissions depend on region, account ownership, amount, project membership, data sensitivity, or temporary status, adding roles creates role explosion: East Region Sales Manager, South Region Sales Manager, Enterprise Account Sales Manager, Acting Manager, and so on. The role count grows without expressing the rules precisely.

Use a hybrid model instead:

• Roles determine baseline capabilities;
• Organization, resource, time, or business attributes determine data scope;
• Approval and temporary grants handle exceptions;
• High-risk actions require confirmation or dual control.

Whatever the model, follow least privilege and default deny: without explicit authorization, access remains closed.

03 Build the Permission Matrix Before Drawing Screens

Here is a simplified CRM permission matrix:

Do not write only yes or no. Specify data scope, conditions, states, and exceptions. “Can edit” should prompt further questions: only records the user created? Still editable after approval? Are sensitive fields exceptions?

04 Entry Treatment: Hidden, Disabled, or Read-Only?

These states communicate different meanings.

When to Hide

Hide modules users will never use or need to know about, such as system configuration for ordinary employees. Hiding reduces noise but never replaces server-side authorization.

When to Disable and Explain

Keep a control visible when users know the feature exists but current conditions are unmet, such as “Export is available after identity verification.” Explain the reason and next step.

When to Use Read-Only

Use read-only presentation when users need information but must not modify it, such as finance viewing a contract or an approver viewing an archived request. Make the state explicit so it does not look broken.

05 Derive Data Permissions From Resource Relationships

“Own, department, all” works for some organizations but not all. In project organizations, matrices, or external collaboration, data scope may derive from:

• Record creator;
• Current owner;
• Project membership;
• Customer and account-team membership;
• Organization tree and region;
• Data sensitivity;
• Contract or task state;
• Temporary authorization period.

Explain the current scope in the interface. A list heading, filter, or notice such as “Viewing all customers in the East Region” prevents users from assuming the displayed records are all the system contains.

06 Do Not Turn Field Permissions Into a Mysterious Half-Empty Form

When some fields are invisible, consider both layout and business meaning. Hiding sensitive fields entirely is reasonable, but if their absence could mislead users, provide a placeholder such as “This information is visible only to Finance.”

Editable fields also differ:

• Always editable;
• Editable only in draft;
• Changes require reapproval;
• Only a change request can be submitted;
• Only the field owner can maintain it.

These rules must align across field state, help text, and backend validation.

07 What Happens to an Active Session After Permission Changes?

After an administrator revokes access, does a signed-in user's session change immediately? Can an open page still save? Should an export job be canceled? Teams often postpone these questions until development.

For high-risk permissions, define:

• When permissions are recalculated;
• How long caches persist;
• Whether long jobs use permissions at submission or execution;
• When temporary grants expire;
• How revoked users are notified;
• Whether changes enter the audit log.

08 Interface Permissions and Backend Authorization Must Align

Hiding a frontend button only improves experience. The backend must authorize every request against the specific resource; reaching the page does not make later actions valid.

Test at least:

• Changing request parameters to access another person's record;
• Opening an unauthorized link directly;
• Calling privileged APIs from a low-privilege account;
• Continuing to use an old page after access is revoked;
• Mixing unauthorized records into a batch action;
• Leaks through export, search, or statistics;
• Error messages revealing that a sensitive resource exists.

09 Design Administration So Permissions Stay Manageable

The permission-management interface should answer who, to what, and what they can do. Provide:

• Role descriptions and intended users;
• Permissions grouped by business module rather than API name;
• Separate labels for high-risk permissions;
• Impact preview before a role changes;
• Sources of direct and inherited access;
• Expiration for temporary permissions;
• Conflict and overpermission warnings;
• Change records, operator, and reason.

Do not make administrators select blindly from hundreds of checkboxes. Offer preset roles for common jobs, then configure a limited set of attributes and exceptions.

10 Permission Design Delivery Checklist

• User, role, organization, and resource relationship diagram;
• Menu, page, data, action, and field permission matrices;
• Critical tasks and interface differences by role;
• Rules for hiding, disabling, read-only access, and access requests;
• Permission changes, delegation, expiration, and exception flows;
• Frontend-to-backend permission mapping;
• Audit-log fields and search methods;
• Security test and acceptance scenarios.

Frequently Asked Questions

Can one user have multiple roles?

Yes, but define whether permissions are additive, prioritized, or mutually exclusive. High-risk systems should check whether role combinations violate separation of duties, such as one person initiating and finally approving the same payment.

Should an unauthorized button be hidden or disabled?

It depends on whether users need to know the function exists. Hide permanently irrelevant functions; keep and explain actions temporarily unavailable because of state, plan, or workflow conditions. Security enforcement is independent of presentation.

Should a super administrator have every business permission?

Not necessarily. System configuration and business approval can be separate. Technical administrators may maintain the system without seeing every sensitive record or making business decisions.

Who owns permission rules: product, engineering, or security?

Business owners define responsibility and boundaries; product and design translate rules into tasks and interfaces; engineering enforces server authorization; security and QA test bypasses. No one function can complete the work alone.

11 Put Research and Design Into Product Decisions