資料權限是SaaS産品必不可少的功能，明确權限管控的顆粒度，保障資料安全。本文作者對如何SaaS 産品的資料權限該如何設計展開了分析，希望對你有幫助。
最近正好在做資料權限這塊的産品設計，同時拆解完紛享銷客的 PaaS 平台後，又受到了新的啟發。事實上，我發現不少 SaaS 的産品經理都沒有接觸過資料權限這塊的産品設計 —— 通常，如果經曆過從0-1的 SaaS 産品過程的話，就會知道資料權限是一開始就需要設計和開發的。
本篇就來和大家講講如何設計資料權限産品功能。
一、資料權限是什麼？
我想如果面試的時候來問産品經理這個問題，估計會得到很多不一樣的答案。簡單的回答可能就是“對系統的資料進行通路控制”，而這相當于沒有回答。
實際上，我認為要從三個方面回答這個問題。
- 一是控制登入人通路的資料範圍，不該看的不能看；
- 二是控制登入人操作資料的行為，不該管的不能管；
- 三是控制登入人能夠檢視的業務對象屬性，敏感的屬性要管控。
資料權限一是控制登入人通路的資料範圍，不該看的不能看；二是控制登入人操作資料的行為，不該管的不能管；三是控制登入人能夠檢視的業務對象屬性，敏感的屬性要管控。
二、怎麼控制資料權限？
我們來看看應該怎麼來控制登入人的資料權限，這裡可以分為資料範圍權限控制、資料操作權限控制和業務對象字段權限控制。
1. 資料範圍權限控制
B 端客戶内部的業務對象通常來說會按管理層級劃分管轄範圍，比如我曾經做過的物業平台，他們會按小區（也叫物業項目）、片區、分公司、大區和總部五個層級來劃分管轄範圍。
這裡的小區其實就是一個基礎的授權業務對象，然後将多個小區集合起來會形成片區。同時，經營小區的會是具有法人資質的主體，即分公司。多個分公司又會按地理區域劃分到不同的大區，最後到總部管轄全部的業務資料。這個時候，我們就需要支援從基礎的業務對象到更大範圍的資料授權。
比如下面幾個場景：
- A 小區的物業項目經理授權 A 小區，他隻能看到 A 小區的各類業務資料（報修、投訴、收費等等）；
- B 片區的物業片區經理授權 B 片區，他能夠看到 B 片區下的全部小區的各類業務資料，包括以後在 B 片區再新增的小區。
- C 公司的物業分公司總經理授權 C公司，他能夠看到C 公司下的全部小區的各類業務資料，包括以後在C 公司再新增的小區。
- D 大區的物業大區經理授權D大區，他能夠看到D 大區下的全部小區的各類業務資料，包括以後在 D大區下各個分公司新增的小區。
- 總部的集團上司可以看到全部的小區各類業務資料。
通常來說，不同層級的授權方式是互斥的，也就是一個人不能說既按小區級别授權又按片區級别授權。同時，同一個層級的，是支援授權多個的。
對于 B 端客戶的外部業務對象，因為不存在管轄層級，往往是通過配置設定的方式進行。即将一個或多個業務對象配置設定給某類角色或某個員工，登入人隻能看到配置設定給自己的業務對象。典型的就是 CRM 系統的客戶公海資源，員工隻能看到配置設定給自己的客戶。
2. 業務對象操作權限控制
業務對象操作權限是指對業務對象以及業務對象屬性能夠進行的操作。典型的業務對象的操作就是新增、删除、編輯、檢視、導出、改變業務對象狀态（如市場線索轉銷售線索）等等。比方說，我們控制 A 員工隻能檢視客戶資訊，不能新增、編輯、删除和導出客戶資訊。
3. 業務對象字段權限控制
業務對象字段的顆粒度就更小一點，是針對某個類型的業務對象，限制登入人能檢視、編輯或導出業務對象的哪些屬性。業務對象屬性在技術上對應的是資料表的字段。
舉個例子，CRM 系統的“客戶”這個業務對象，會有名稱、位址、電話、級别、所屬行業等等資訊。我們就可以控制A 員工（或角色）隻能檢視客戶名稱、級别和所屬行業，不允許檢視位址和電話。
三、資料權限産品設計
接下來我們看資料權限的産品怎麼設計。
1. 資料範圍權限設計
資料範圍權限控制首先我們要明确系統的基礎業務對象，比如物業平台的小區、房地産管理的樓盤、WMS的倉庫、線下商超的門店等等，這些都可以作為基礎的授權業務對象。然後，基于基礎業務對象建構管理層級，劃分到不同層級的不同集合裡。之後，就可以授權某個角色或人員擁有的管轄範圍，下面是一個示例。
給業務對象配置設定成員的比較簡單，基于業務對象添加成員或者移除成員即可，在文檔協作類産品非常常見。
2. 業務對象操作權限設計
控制業務對象的操作權限，我們首先要基于某類業務對象定義好這類業務對象有哪些操作，然後再勾選某個角色或人員有能夠進行哪些操作。
業務對象的操作涉及如下資訊：
- 操作名稱：比如操作按鈕的名稱；
- 操作辨別：系統全局唯一的辨別，前端可以通過這個辨別來決定是否展示相應的操作入口；
- 顯示方式：即操作入口是隐藏還是禁用。隐藏是比較常見的操作，但是禁用的話可以讓登入人知道他沒有這個權限，如果需要可以找他們内部的管理者開通。
- 對應資料接口：即對應操作的資料接口，這個是防止有人知道了資料接口，繞過操作按鈕直接通路接口來獲得資料，通過同時禁止資料接口的通路權的安全等級會更高一些。
下面是紛享銷客的業務對象操作權限控制的界面，大家可以參考一下。
3. 字段操作權限設計
字段操作權限和業務對象操作權限類似，我們也需要先定義好業務對象的字段屬性，主要的資訊如下：
- 名稱：字段的顯示名稱，如姓名、手機号等都是字段的名稱；
- 資料表字段名：對應業務對象資料表的字段名，技術上需要通過這個字段名來控制字段的權限；
- 顯示方式：即未授權該字段時該如何顯示，目前有兩種做法，一是直接隐藏；二是脫敏。直接隐藏比較簡單，但是可能會引起頁面布局不美觀；脫敏則是隐藏掉部分的内容，比如手機号中間4位使用“*”号替代，這種方式的好處是頁面布局不需要改動，但需要開發做一定的處理。
- 是否必選：有些字段是不能來控制權限的，比如客戶名稱，如果客戶名稱都不顯示了，那麼這條資料都沒有意義了，是以需要定義業務對象的主要字段是必須勾選的，不可以禁止相應的字段權限。
字段的操作一般隻有讀取、編輯和導出，是以字段操作上不需要單獨管理。下面同樣給出了紛享銷客的字段授權的界面，供大家參考。
四、總結
總的來說，資料權限的授權分為三個方面，業務對象範圍授權、業務對象操作授權和業務對象字段授權。
為了實作這三個方式的授權，我們在産品設計上需要支援業務對象範圍的劃分、業務對象操作的定義和業務對象字段的定義，如下圖所示。之後，我們就可以配置某個角色或人員的資料權限了。
資料權限是SaaS産品必不可少的功能。企業的資料很多涉及敏感資訊，包括商業機密資訊等等，是以必須在産品規劃之初就明确權限管控的顆粒度，以及按何種方式管理資料權限。希望看了本篇之後，能夠給大家一些參考和啟發。
專欄作家
産品海豚灣，公衆号：産品海豚灣（ID：pm-dophin-bay），人人都是産品經理專欄作家。技術出身的産品經理，從事過 C 端産品和 B 端産品設計，擅長 SaaS 産品設計、産品架構設計和需求分析。負責的B 端産品完成了完整的從0到1，從1到 N 的過程，成功簽約行業百強客戶。
本文原創釋出于人人都是産品經理，未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協定。
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。