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

一、功能權(quán)限

1. 是否可見

目標(biāo)：控制某個(gè)菜單某個(gè)按鈕是否對(duì)訪問用戶開放。

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

2. 能否操作

目標(biāo)：進(jìn)一步控制訪問用戶是否能對(duì)可見按鈕進(jìn)行操作。

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

解決方案：當(dāng)權(quán)限需要在此類場(chǎng)景下細(xì)化時(shí)，可進(jìn)一步對(duì)按鈕權(quán)限進(jìn)行控制，比如定義只有工單負(fù)責(zé)人及其上級(jí)主管可操作。

3. 注意事項(xiàng)

1）必須按實(shí)際的業(yè)務(wù)場(chǎng)景需求進(jìn)行角色初始化，大部分用戶都是很懶的

做了8年产品经理后，我是这么看产品经理的

我个人是从非常初级的产品经理做起，再到负责一个大产品的项目管理，现在有幸跳出了日常基础的工作更多的去看产品的PMF，product strategy...

查看详情 >

2）預(yù)設(shè)角色不能編輯權(quán)限，否則后期迭代功能上新時(shí)，就無法自動(dòng)為這些預(yù)設(shè)角色勾選新功能了

二、數(shù)據(jù)權(quán)限

1. 通用場(chǎng)景

目標(biāo)：依托組織架構(gòu)實(shí)現(xiàn)數(shù)據(jù)權(quán)限的控制。

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

2. 特殊場(chǎng)景

目標(biāo)：脫離組織架構(gòu)實(shí)現(xiàn)數(shù)據(jù)權(quán)限的控制。

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

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

場(chǎng)景2：希望能將自己的某個(gè)客戶共享給其他人。

解決方案2：從業(yè)務(wù)上進(jìn)行場(chǎng)景定義，比如設(shè)置協(xié)作人字段等。

場(chǎng)景3：設(shè)置節(jié)點(diǎn)流程的審批人。

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