SaaS系統(tǒng)權限架構設計主要包括功能權限和數(shù)據(jù)權限，前者控制用戶對某個菜單某個按鈕是否可見、能否操作，后者控制用戶能看到什么層級的數(shù)據(jù)。

一、功能權限

1. 是否可見

目標：控制某個菜單某個按鈕是否對訪問用戶開放。

解決方案：RBAC模型，基于角色的訪問控制。1個用戶可以有多個角色，每個角色又賦予了多個系統(tǒng)權限點，最終實現(xiàn)用戶與權限的關聯(lián)關系。

2. 能否操作

目標：進一步控制訪問用戶是否能對可見按鈕進行操作。

場景說明：一般情況下，可見按鈕均是可以操作的，不會做特別的權限控制，但在某些場景下，比如銷售在看客戶詳情時，可以通過鏈接查看工單詳情，那他是否可以操作工單上的按鈕？

解決方案：當權限需要在此類場景下細化時，可進一步對按鈕權限進行控制，比如定義只有工單負責人及其上級主管可操作。

3. 注意事項

1）必須按實際的業(yè)務場景需求進行角色初始化，大部分用戶都是很懶的

2）預設角色不能編輯權限，否則后期迭代功能上新時，就無法自動為這些預設角色勾選新功能了

二、數(shù)據(jù)權限

1. 通用場景

目標：依托組織架構實現(xiàn)數(shù)據(jù)權限的控制。

解決方案：對組織架構內(nèi)的員工定義數(shù)據(jù)權限，比如只能看自己的數(shù)據(jù)，只能看本部門數(shù)據(jù)，可以看本部門及下級部門數(shù)據(jù)。

2. 特殊場景

目標：脫離組織架構實現(xiàn)數(shù)據(jù)權限的控制。

場景1：希望跨組織架構看到其他部門的數(shù)據(jù)，比如質檢部門需要看到銷售部門的數(shù)據(jù)。

解決方案1：設置共享權限，單獨共享某個部門或人維度的數(shù)據(jù)。

場景2：希望能將自己的某個客戶共享給其他人。

解決方案2：從業(yè)務上進行場景定義，比如設置協(xié)作人字段等。

場景3：設置節(jié)點流程的審批人。

解決方案3：在流程配置頁面設置審批人，比如指定角色？指定人？直接主管？