我們常接觸到的數據訪問權限都通過組織機構去劃分，在實際應用中，也可能會根據業務增加其他維度的訪問權限，如終端門店管理中單獨設置門店訪問權限，企業多品牌營銷中設置品牌訪問權限等。
1、以機構層級向下覆蓋
根據組織機構樹設定用戶默認擁有所屬組織及以下的數據訪問權限。也是最基礎的壹種數據權限，對於簡單的
2、與角色融合的數據訪問權限
在設定角色時，同時設置該角色對應功能權限下的的數據訪問權限層級：本人、本部門、本部門及以下、全公司。
用戶可視菜單中的數據權限由擁有該菜單的角色數據權限而定，且當壹個用戶擁有多個角色時，角色菜單有重疊的，取兩角色中最大數據權限，或數據權限並集。
3、設置部門訪問權限
用戶默認擁有所屬組織及下級組織的訪問權限，同時可以自由配置其他部門的訪問權限，使得某些數據可以跨部門查看。
相比常規的基於企業組織架構，權限向下覆蓋的方式，采用部門訪問權限配置可以根據業務需求靈活地配置用戶的訪問數據範圍，避免了父、子、兄弟甚至其他節點間的數據***享糾結，實現跨部門數據***享。
將數據訪問權限分配在用戶上，足夠靈活但也犧牲了維護便捷性，在用戶特殊訪問權限不多的情況下可以選擇該類方法進行設置。
4、實際應用中根據業務需要劃定數據及功能權限範圍
在實際應用中，僅通過部門設置數據訪問權限不壹定能滿足業務數據的分界要求，在具體的功能裏往往通過部門訪問權限+其他條件組合的情況來限制用戶數據權限範圍。
如部門訪問權限+角色標簽，公司內部有領導類的角色，某種業務的原始單據信息需要給高層領導類角色的查看權限，但涉及到管理分權又不想賦予該類人員所有部門訪問權限，此時要麽單獨開入口查詢所有信息，領導類角色功能權限中都配置上該頁面，也可以在該頁面查詢數據時，在部門訪問權限之前再加壹層角色標簽的判斷邏輯，若角色標簽為領導的則不需要根據部門訪問權限過濾。
總結及碎碎念
B端系統權限設計中，系統權限區分為功能權限和數據權限，分別對應系統中的功能模塊和系統中的數據，功能權限大多基於RBAC模型，並可根據業務需要引入角色繼承、用戶組、角色標簽等概念，數據權限主要基於用戶機構、角色，或單獨在頁面中根據實際需要進行配置。但最終，所有的設置都是需要基於業務，先有業務、需求後有產品，只是權限配置這壹功能模塊偏向於公司層面要求，受公司業務形態影響較小，所以能抽象出壹套較廣泛適用的系統方法。