How to Design B2B Data Permissions: Department, Own Records, All Data, and Custom Scopes

Hiding a menu does not protect data. B2B permissions must address objects, actions, data scope, fields, states, and duration together, and tell users why they can view something or cannot act.

Hiding a menu does not protect data. B2B permissions must address objects, actions, data scope, fields, states, and duration together, and tell users why they can view something or cannot act.

01 Separate Two Questions: What Can Users Do, and Which Data Can They See?

Many systems configure permissions as menu checkboxes: selecting "Customer Management" lets users enter the page; clearing it hides the menu. This controls the feature entry point, not the data boundary. A hidden menu does not prevent an API from returning prohibited customers; permission to view a customer does not imply permission to export, transfer, or delete it.

A mature permission model answers at least four questions: who may perform which action on what type of object under which conditions? Role is only one input. Department, project membership, data ownership, sensitivity, and temporary access also change the result.

02 Do Not Put Feature and Data Permissions into One Switch

Organize the configuration interface by these layers. Select the role or user, choose business objects and actions, then set data scope and exceptions. Flattening "view own customers," "edit own customers," and "view department customers" into hundreds of checkboxes is easy to develop initially and nearly impossible to maintain later.

03 "Own," "Department," and "All" Each Conceal Boundary Questions

Own: Based on Creator, Owner, or Participant?

A customer record may be created by A, assigned to B, and include C as a collaborator. If "own data" is undefined, permission outcomes change with each developer's interpretation. Define ownership separately for each object rather than sharing one owner field across the system.

Department: Current Department Only, or Subordinate Organizations Too?

Organizations change and employees transfer. Decide whether department scope follows the hierarchy dynamically or remains a snapshot from the authorization date; whether cross-department projects, matrix reporting, and virtual teams count; and whether managers automatically see all subordinate data.

All: Truly Everything, or Everything in the Tenant?

In multi-tenant SaaS, "all data" generally means all data inside the current enterprise tenant, never across customer organizations. Cross-tenant access by platform operators needs separate internal permissions, approval, and audit, not reuse of the ordinary enterprise administrator role.

Custom Scope: Do Not Show Only an Organization Tree

Complex businesses may need "all East China customers plus nationwide key accounts minus one sensitive project." Department selection alone is insufficient. Allow rules combining organization, project, tag, business line, or data attributes, and show sample match counts so administrators do not save conditions they cannot understand.

04 Roles Are a Starting Point, Not the Only Answer

RBAC expresses stable responsibilities such as Sales, Finance, or Reviewer. When permission depends on data attributes and context, add attribute or relationship checks—for example, "a contract owner can edit owned contracts in Draft" or "project members may view files only for projects they participate in."

05 Tell Users Why an Action Is Unavailable

Some capabilities should be hidden; others should remain visible but disabled. The decision is not about visual neatness. It depends on whether users know the capability exists and have a legitimate path to obtain it.

• Hide completely unrelated modules to reduce noise.
• For known actions blocked by the current state, show a disabled control with the condition, such as "An active contract cannot be deleted directly."
• For permissions that can be requested, provide "Request Access" or a contact instead of only a 403 error.
• Calculate list totals, dashboard cards, and search suggestions under the same permission scope to avoid leaking data through aggregates.
• Evaluate export, bulk actions, link copying, and API access separately; they often carry more risk than viewing a page.

The most dangerous permission defect is not one extra button but inconsistent rules across entry points: a record hidden in the list appears in search, or a page masks a field while an export contains the original value.

06 Turn Rules into a Reviewable Permission Matrix

A matrix is not the final code, but it helps product, business, security, and development teams discuss the same rules. If a cell says "It depends," continue defining the state, amount, ownership, or approval condition.

07 Permission Scenarios That Must Be Tested

• When one user has two roles, determine whether permissions use the union, intersection, or explicit-deny precedence.
• After employee transfer, departure, or organization merger, determine how historical data and active tasks move.
• Verify that URLs, search, notifications, recent items, and export cannot bypass list permissions.
• When a user can view a record but lacks field permission, confirm the API does not still return the sensitive original value.
• When a bulk action includes unauthorized records, determine whether all fail, unauthorized items are skipped, or users must revise the selection.
• After temporary access expires, approval is withdrawn, or an account is frozen, ensure caches and open pages expire promptly.
• When an administrator views or acts on sensitive data for another user, record the reason, time, and affected objects.

08 Common Questions About Permission Design

If the Menu Is Hidden, Is Backend Validation Still Needed?

Absolutely. Frontend hiding only improves the interface; users may still request data through APIs, saved links, or other entry points. Authorization must run on the server for every request.

Do More Roles Make Permissions More Precise?

Not necessarily. Role explosion usually means data scopes, state conditions, and temporary relationships were hard-coded as roles. Separate actions from scope first, then decide which stable combinations deserve a role.

Should a Super Administrator Access All Business Data?

Not by default. Separate system configuration from business-data access. When troubleshooting or proxy handling is necessary, use controlled temporary access, secondary confirmation, and full auditing.

Must Permission Changes Take Effect Immediately?

High-risk revocations should apply quickly to tokens, caches, and open sessions. Ordinary additions may have some delay, but the interface should show activation status so administrators do not assume a saved change has synchronized.

09 Make Permissions Explainable Business Rules

A permission model is not a configuration table added near the end of development. It jointly expresses business boundaries, organizational relationships, and risk controls. Define objects, actions, scope, conditions, and duration before roles and interfaces so the system remains maintainable as the organization changes.