當前使用最普遍的是RBAC模型，即用戶-角色-權限。該模型可以滿足大部分的業務場景，較為細化復雜的權限，也可結合ABAC模型來實現。
系統會有若幹個功能，但是不同模塊功能會對應企業中不同的管理者，那麽權限不盡相同。為了靈活分配給不同用戶不同權限，衍生出了用戶-角色-權限模型，壹個角色封裝多個權限操作，可直接將該角色分配給用戶：
若大量用戶使用同壹個角色，則每次分配，仍會有很多重復勞動，所以衍生出了「用戶組」的概念，將用戶綁定到壹個組上，可為這個組賦予壹個角色，組下的用戶均有這個角色：
同理，角色之間有很多相同的權限，每個維護角色時都要勾選大量的權限，因此可以增加「權限組」的概念，將通用的權限打包成組，分配給角色。
在設計系統時，可具體問題具體分析，較簡單的系統，無需設計的太過復雜，越復雜越靈活，同時越靈活也越復雜；要考慮實際業務場景、培訓成本等各個因素。在設計表結構的時候，可以預留出組的概念，產品設計層面0到1，無需設計過於復雜。
用戶，即賬號的概念，登錄系統要有賬號，賬號關聯著角色，決定可以看到什麽、操作什麽；每個賬號可看到的數據範圍也各有不同，因此可以根據不用行業的字段屬性，去為賬號配置數據範圍，也就是基於屬性的權限驗證（ABAC: Attribute-Based Access Control）。
權限可以再細分為字段權限和菜單功能權限，不同賬號進入系統時，看到的菜單、菜單中的功能都有所不同，進入同壹個頁面時，頁面中的字段是否展示，也各不相同。
因此，我們在設計權限體系時，可以參考該思考方式去設計。
5步搭建權限管理：創建賬號、創建角色、字段權限設計、菜單功能權限設計、數據範圍設計。本文將以人事系統為例，進行權限搭建說明。
孤立的系統，可單獨設計註冊邏輯、後臺添加賬號邏輯進行賬號的創建；人事系統作為員工入離職的核心，因此可在入職成功時，系統自動為其創建壹個單點登錄賬號；離職時，自動失效賬號。
如果需要引用用戶組的概念，則可根據壹些特定的規則，例如部門、崗位等，自動加入某用戶組。也可設計頁面為其手動維護到用戶組中。
創建角色時，可設置該角色屬於哪個角色組，沒有角色組概念則可忽略；是否可向下賦權，即該角色是否可設置子角色並分配權限，壹般非集團企業，可不進行此設計。
壹般情況下，創建角色只要維護角色名稱和描述即可。較為復雜的，可引入角色組或向下賦權的概念，例如集團企業。
在角色下，可為不同系統模塊分配字段權限；例如，在員工管理模塊，可編輯基本信息、工作信息、學歷信息，在個人檔案模塊僅可只讀基礎信息（具體如何設計系統表結構、字段等，本文不做詳細說明，後面有機會會在別的文章進行說明）。
賬號是否有菜單功能權限，即是否配置了相關的接口權限；在產品設計時，需要梳理好各個頁面功能的顆粒度，這樣研發同學在拆分接口的時候，才能更好的規劃。
壹般權限配置都是由系統管理員來完成，所以保證邏輯通暢、頁面較清晰即可；商業化的產品，壹般會將菜單功能梳理出來列舉好，讓用戶學會自己勾選配置，通常層級為：目錄模塊-菜單-功能。如果是內部系統定制化開發，則可不必拘泥於形式，能配置即可，例如下圖，先在後臺把菜單與功能的接口配置好，再在角色中勾選這些接口，組合成角色-權限。
當多個人擁有相同的菜單和功能，但管理的數據範圍有所不同時；例如：A和B同樣是HRBP，管理著團隊的入離職等情況，但A負責的是產品部，B負責的是企業內所有組長等。此時就需要為不同人劃分不同的數據範圍，由於人事系統主要的劃分屬性來源於員工屬性，因此在設計員工表的時候，可根據業務劃分成不同對象（或者說是表），對象下擁有不同的字段（或者說是員工屬性），再根據字段的不同類型，將邏輯判斷區分出來；例如，日期格式字段，邏輯判斷可為＞/≥/＜/≤/介於/≠/＝等；字典值字段，邏輯判斷可為屬於/不屬於/為空/不為空等。
如果是其他行業，則可根據具體場景劃分出不同屬性；這個就是基於屬性的權限驗證（ABAC: Attribute-Based Access Control）。
當每個人都有數據範圍時，在做數據***享類似功能時，例如員工檔案數據分享時，可僅分享數據統計的邏輯、數據來源，而能看到哪些字段和數據範圍則取決於賬號本身的權限。
壹般針對中小型企業的商業化產品的權限都不會做的過於復雜，但是萬變不離其宗，無論頁面如何設置，其本質沒有什麽變化。以釘釘舉例，釘釘在設置管理範圍時，僅支持按組織架構劃分，由於釘釘人事模塊是後發展起來的，壹開始並沒有過多的內置各種屬性字段，因此管理範圍也只能做成根據組織架構劃分。但是日常基本夠用了。
當「智能人事」中權限選擇細分時，可以看到在單獨這個業務下，釘釘也是劃分了不同的人事模塊，並且不同模塊可單獨配置字段權限，雖然現在只有員工檔案壹個模塊。但是可以看到架構基本還是這壹套，後面也支持各種擴展。