SaaS系統權限架構設計主要包括功能權限和數據權限，前者控制用戶對某個菜單某個按鈕是否可見、能否操作，後者控制用戶能看到什麼層級的數據。

一、功能權限

1. 是否可見

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

解決方案：RBAC模型，基於角色的訪問控制。1個用戶可以有多個角色，每個角色又賦予了多個系統權限點，最終實現用戶與權限的關聯關系。

2. 能否操作

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

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

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

3. 註意事項

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

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

二、數據權限

1. 通用場景

目標：依托組織架構實現數據權限的控制。

解決方案：對組織架構內的員工定義數據權限，比如隻能看自己的數據，隻能看本部門數據，可以看本部門及下級部門數據。

2. 特殊場景

目標：脫離組織架構實現數據權限的控制。

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

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

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

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

場景3：設置節點流程的審批人。

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

作者：D.lemon，公眾號：檸檬的產品小記

本文由 @D.lemon 原創發佈於人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。