目前，最常用的RBAC模型是用戶-角色-權限。該模型可以滿足大多數業務場景，細化復雜權限，也可以結合ABAC模型實現。
系統會有幾個功能，但是不同的模塊功能會對應企業中不同的管理者，所以權限也不壹樣。為了靈活地為不同的用戶分配不同的權限，提出了用戶-角色-權限模型。壹個角色封裝了多個權限操作，可以直接分配給用戶:
如果大量用戶使用同壹個角色，每次分配還是會有大量的重復性工作，於是就衍生出了“用戶組”的概念。通過將用戶綁定到壹個組，該組可以被賦予壹個角色，並且該組下的所有用戶都具有該角色:
同理，角色之間有很多相同的權限，維護角色時必須檢查大量的權限。所以可以加入“權限組”的概念，將常用權限打包成組，分配給角色。
在設計壹個系統的時候，我們可以具體問題具體分析。更簡單的系統不需要太復雜。越復雜越靈活，越靈活。要考慮實際業務場景、培訓成本等各種因素。在設計表結構的時候，可以保留組的概念，產品設計級別是0到1，所以設計不太復雜。
用戶，也就是賬號的概念，登錄系統必須有賬號，賬號和角色關聯，決定了妳能看到什麽，能操作什麽；每個賬戶可以看到的數據範圍也是不壹樣的，可以根據不同行業的字段屬性為賬戶配置數據範圍，也就是基於屬性的訪問控制(ABAC)。
權限可以細分為字段權限和菜單功能權限。當不同的賬戶進入系統時，他們會在菜單中看到不同的菜單和功能。當他們進入同壹個頁面時，頁面中的字段是否顯示也是不同的。
所以我們在設計權限體系的時候，可以參考這種思維方式來設計。
5.建立權限管理:創建賬戶、創建角色、設計字段權限、設計菜單功能權限、設計數據範圍。本文將以人事制度為例來闡述權威建設。
在隔離系統中，可以單獨設計註冊邏輯，後臺添加賬戶邏輯創建賬戶；人事系統作為員工入職和離職的核心，可以在員工入職成功時自動為其創建單點登錄賬戶。離職時，賬號自動失效。
如果需要引用用戶組的概念，可以按照壹些特定的規則，比如部門、崗位等，自動加入壹個用戶組。妳也可以將手工維護的頁面設計成用戶組。
創建角色時，可以設置角色屬於哪個角色組。如果沒有角色組的概念，可以忽略。角色是否可以向下委托，即角色是否可以設置子角色和分配權限，非集團企業壹般不要求。
壹般來說，創建角色只需要維護角色名稱和描述。更復雜的，可以引入角色組或者向下賦能的概念，比如集團企業。
在角色下，可以為不同的系統模塊分配字段權限；比如在員工管理模塊中，可以編輯基本信息、工作信息、學歷信息，而在個人檔案模塊中，只能讀取基本信息(如何設計系統表結構、字段等。不在本文詳細解釋，後面其他文章會解釋)。
賬戶是否有菜單功能權限，即是否配置了相關界面權限；在產品設計中，需要對各個頁面功能的粒度進行梳理，以便R&D同學在拆分界面時更好的規劃。
壹般權限的配置都是由系統管理員來完成的，所以保證邏輯流暢，頁面清晰就夠了；商業化的產品壹般會把菜單功能整理出來列出來，讓用戶學會自己查看配置。通常層次是:目錄模塊-菜單-功能。如果內部系統是定制的，可以不正式配置。比如下圖，先在後臺配置菜單和功能的接口，然後在角色中勾選這些接口，形成壹個角色權限。
當多人擁有相同的菜單和功能，但管理的數據範圍不同時；比如A和B都是HRBP，管理團隊的進出，但是A負責產品部門，B負責企業內所有的團隊領導。這時候就需要針對不同的人劃分不同的數據範圍。因為人事系統的主要劃分屬性來自於員工屬性，所以在設計員工表時，可以根據業務劃分成不同的對象(或表)，在對象下有不同的字段(或員工屬性)，然後根據字段類型的不同進行邏輯判斷；例如，在日期格式字段中，邏輯判斷可以是>/≥/
如果是其他行業，可以根據具體場景劃分不同屬性；這就是ABAC(基於屬性的訪問控制)。
當每個人都有壹個數據範圍的時候，在做數據共享的時候，比如員工檔案數據共享，妳只能共享數據統計的邏輯和數據源，妳能看到哪些字段和數據範圍取決於賬號本身的權限。
壹般來說，中小企業商業產品的權限不會太復雜，但絕對不會變，而且無論頁面怎麽設置，其本質都不會變。以釘釘為例。在設置管理範圍時，釘釘只支持按照組織架構進行劃分。因為釘釘人事模塊開發的比較晚，壹開始沒有太多內置的屬性字段，所以只能按照組織架構來劃分管理範圍。但是日常生活基本夠用。
當智能人事中的權限進行細分時，可以看到，在單壹業務下，釘釘還分為不同的人事模塊，不同的模塊可以分別配置字段權限，雖然現在只有員工檔案壹個模塊。不過可以看到架構基本壹致，後期也支持各種擴展。