Designing a Scalable Three‑Tier Permission Model: Functional, Data, and Approval

In digital systems, user, role, and menu form the basic triad of permission management. As enterprises move to fine‑grained governance, the classic RBAC model shows limitations, leading to a three‑tier permission system (functional, data, approval) where data permission is the key breakthrough.

Core Concept Analysis

Functional Permission Defines the boundary of system functions a user can access, typically implemented with RBAC. Role‑menu mapping provides hierarchical control of feature visibility.

Data Permission Controls the data granularity a user can see within the functional boundary, realized by dynamic data filtering. A typical implementation injects query conditions, e.g. limiting a regional manager to its own region: SELECT * FROM orders WHERE region_code = 'HF'; Data Scope The actual subset of data a user can access, often multi‑dimensional. For example, the intersection of "East China" and "Education" product line defines a precise data set.

Control Dimension The concrete carrier of data permission that maps directly to business attributes. Common dimensions include:

Geographic (region, store)

Commercial (channel partner, distributor level)

Product (product line, SKU category)

Process (sales channel, business unit)

Solution 1: Role‑Menu Binding

This classic approach binds menus to permission dimensions and links roles to menu instances, achieving menu‑level precision. However, it suffers from "role explosion": each geographic or business variant requires a separate role instance, causing linear growth in role count and maintenance overhead.

Solution 2: User‑Role‑Scope Binding

This model binds users directly to data scopes, reducing role count. While it simplifies management, it forces all functional modules to share the same data‑filtering rules, limiting flexibility when different modules require distinct dimensions (e.g., region vs. product line).

Solution 3: Menu‑Bound Control Dimension + User Data Scope

This hybrid combines the previous two ideas: menus are bound to control dimensions, while users are assigned data scopes. The drawback is permission expansion—when a user holds multiple scope values, they apply to all menus, causing data leakage across modules.

Business requirement: User Zhang can view only Hefei data in purchase orders but only Fuyang data in sales orders.

Effect: Because Zhang holds both Hefei and Fuyang scopes, he sees the union of both datasets in both modules.

The root causes are global scope, lack of fine‑grained control per dimension, and inability to reflect special business scenarios.

Solution 4: Menu‑Bound Authorization Dimension + Role Instance Data Permission

This is the currently used scheme. Menus pre‑define control dimensions; users obtain functional permissions through roles, while data permissions are bound to concrete role instances. Example: a city manager role (with functions A, B, C) and a channel manager role (with functions D, E). When user Xiao Zhang holds both roles, the system assigns Hefei data to the city manager role and Fuyang data to the channel manager role. At runtime, the system automatically switches data scope based on the accessed menu, delivering precise data while keeping functional permissions as a union.

Key advantages:

Accurate matching of functional and data permissions.

Flexible multi‑role configuration without interference.

Automatic menu‑role association enables intelligent data‑scope switching.

Conclusion

We examined four typical data‑permission implementations. The first provides precise control but leads to role explosion; the second simplifies management but sacrifices flexibility; the third mitigates role growth but introduces permission expansion; the fourth, a hybrid of menu‑bound dimensions and role‑instance data binding, resolves both role explosion and data‑scope leakage, offering a scalable and precise permission architecture.