Four Practical Data Permission Models for Scalable Enterprise Systems

In modern digital systems, user, role, and menu form the foundational triad of permission management, but traditional RBAC struggles with multi‑dimensional data control as enterprises move toward fine‑grained governance. A three‑layer model—functional, data, and approval permissions—has emerged as best practice, with data permission being the critical breakthrough.

Core Concepts

Functional Permission : Defines the system functions a user can access, typically implemented via RBAC with role‑menu mappings.

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

Control Dimension : The concrete dimensions that map data permission to business characteristics, such as geographic, commercial, product, and process dimensions.

Solution 1 – Role‑Menu Binding

Classic approach linking menus to permission dimensions and roles to menus, achieving menu‑level control. Drawback: role explosion when many regional variants are needed (e.g., 300 city‑manager roles for 300 regions), leading to high maintenance overhead.

Solution 2 – User‑Role‑Scope Binding

Users are directly assigned data scopes, reducing role count. However, this couples all modules to a single data filter, limiting flexibility when different modules require different dimensions (e.g., region vs. product line).

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

Hybrid model combines advantages of the first two but introduces a permission‑expansion issue: when a user has multiple values in a dimension, those values apply globally across menus, causing data leakage (e.g., a user sees both Hefei and Fuyang data in unrelated modules).

Solution 4 – Menu‑Bound Control Dimension + Role‑Instance‑Bound Data Permission

The adopted design solves role explosion and scope expansion. Menus predefine control dimensions; users obtain functional permissions via roles, while data permissions are bound to specific role instances. Example: a user with both "City Manager" and "Channel Manager" roles gets Hefei data for city‑manager menus and Fuyang data for channel‑manager menus, with automatic switching based on the accessed menu. Shared menus merge data scopes.

Key advantages: precise functional‑data permission matching, flexible multi‑role configuration without interference, and automatic menu‑role data binding, avoiding both role bloat and scope over‑reach.

Conclusion

The evolution of permission management reveals four typical data‑permission schemes. Scheme 1 offers fine control but suffers role explosion; Scheme 2 simplifies management at the cost of flexibility; Scheme 3 introduces permission over‑expansion; Scheme 4, the recommended approach, balances scalability and precision by binding menus to control dimensions and role instances to data scopes.