Mastering Data Permission Architectures: Four Practical Models for Scalable Systems

In the evolution of digital system permission architectures, users, roles, and menus form the foundational triad, but traditional RBAC struggles with multi‑dimensional data control as enterprises move toward fine‑grained governance.

Core Concept Analysis

Functional Permission defines the system functions a user can access, typically implemented via RBAC and role‑menu mappings.

Data Permission controls the data granularity within those functions, usually by injecting dynamic query filters. Example: SELECT * FROM orders WHERE region_code = 'HF'; Data Scope is the actual subset of data a user can see, often multi‑dimensional (e.g., "East China region + Education product line").

Control Dimension is the concrete carrier of data permission, mapping directly to business attributes such as geography, channel, product line, or process.

Geographic dimension (region, store)

Business dimension (channel, distributor level)

Product dimension (product line, SKU)

Process dimension (sales channel, business unit)

Solution 1: Role‑Menu Binding

This classic approach binds menus to permission dimensions and links roles to menus, achieving menu‑level control. However, it leads to "role explosion"—for each geographic unit a separate role instance is required, causing linear growth in maintenance effort.

Solution 2: User‑Role‑Scope Binding

This model ties users directly to data scopes, reducing role count but sacrificing flexibility. All modules must share the same data‑filter rules, making it impossible to apply different dimensions (e.g., region vs. product line) across modules.

Solution 3: Menu‑Control Dimension + User Data Permission

This hybrid combines the previous two ideas: menus are bound to control dimensions, while users receive data‑permission ranges. It simplifies role management but introduces a "permission amplification" problem—if a user has multiple values in one dimension, those values apply to all menus, causing data leakage across modules.

Business requirement: User can view Hefei data in purchase orders and Fuyang data in sales orders.

Actual effect: User sees both Hefei and Fuyang data in both modules.

The root causes are global scope, lack of module‑level isolation, and missing fine‑grained controls.

Solution 4: Menu‑Control Dimension + Role‑Instance Data Permission

This is the currently adopted scheme. Menus pre‑define control dimensions; users obtain functional permissions via roles, while data permissions are bound to specific role instances. For a user holding two roles, each role receives its own data scope, and the system automatically switches the scope based on the accessed menu, ensuring precise data isolation without role explosion.

Summary

We explored four typical data‑permission implementations: (1) role‑menu binding, which offers precise control but suffers from role explosion; (2) user‑scope binding, which simplifies management but limits flexibility; (3) a hybrid that risks permission over‑reach; and (4) the adopted menu‑control plus role‑instance model, which balances scalability and fine‑grained data access.