起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識中后臺學習筆記 – 數據權限
編輯導語：我們常常在數據權限中找不到合適的門路，中后臺的數據權限該怎么設計才能夠滿足我們所需業務的數據權限架構體系？作者給我們從三個方面講解了有關數據權限的知識，我們一起來看下吧。
曾經看到過這樣一個需求：他想知道，我“為什么”能夠看到這條數據? 如果這條數據是我自己創建的，那么其他能看到這條數據的人，都由于什么原因呢?
我的第一反應是：數據權限設計的太復雜了。
隨后又想到: “為什么數據權限要設計的這么復雜呢，有沒有更好的實現方案?”
但在回答這個問題之前，可能要先完成另一件事情，分析清楚到底什么是數據權限? 都有哪些業務場景，需要數據權限的支持?
簡單來講，數據權限就是“用戶是否能夠查看數據”，主要是為了業務系統的信息安全考慮，不同的人，在不同的場景下，所能看到的數據范圍也不一樣。
為了行文方便，后續統一使用“查看數據”進行描述，實際上像增/刪/改/查/鎖定/解鎖/分享等的數據權限類型有很多，就不在本文中介紹了。
本文將結合在工作中遇見的一些業務場景，跟大家分享一些常見的數據權限設計，也希望能夠總結出一套，最符合本公司業務的數據權限架構體系。
一、基礎數據權限
1. 對象級權限
基礎數據權限通常會承載到一個權限媒介上，比如說權限集，職能等。他通常包括兩部分，對象級權限與字段級權限。
簡單來講，對象級權限可以控制到一個用戶是否能夠看到某一個業務菜單或者業務Tab，也就是說用戶甚至可以不知道系統中有這一類的數據。對象級權限的設計會包含下面幾部分。
當然，對于不同的企業，可能還會有更精細的管理，比如針對數據的轉移，鎖定/解鎖等基本功能可以也需要做控制。
關于“查詢所有關聯”和 “修改所有關聯”，他的權限優先級是要高于其他權限規則。比如商機、訂單、報價單等業務對象都關聯了客戶，那么如果在客戶上設置了“查詢所有關聯”的話，就會覆蓋掉具體關聯業務實體設置的對象級權限。
2. 字段級權限
根據業務需要，即使可以看到某個業務對象，但也需要對某些隱私字段做數據權限處理。 例如：聯系人電話、薪水等信息，不會對所有人開放。
如果企業的系統中，有包含頁面布局的相關設置，那么字段級權限設置，要覆蓋掉布局的設置。
二、記錄級數據權限
其實對于很多業務系統來說，可能上面的基礎數據權限設計已經能夠滿足大部分數據權限場景了，但問題是有一類“特殊場景”解決不了。
某“一部分”數據，只允許“一部分”人查看。
幾乎所有復雜的數據權限設計，都是為了解決這個問題，而且因為使用場景差異太大，很難找到一個一攬子解決方案。所以需要多種方案結合，才能在便捷性、安全性上，滿足中大企業復雜的數據權限要求。
1. 系統默認權限
要想解決 某“一部分”數據，只允許“一部分”人操作，理論上那就意味著每一條數據都應該可以被控制。
那么 每一個用戶與每一條數據之間到底是什么關系，是業務系統需要回答的第一個問題。
通常來講，系統默認權限應該是“最嚴格的”，“唯一”的“限制”數據權限的方式，其他的記錄級數據權限，應該是在系統默認權限的基礎上，增加額外的數據權限。
比如最極端的限制條件，所有的業務數據都是不可見的。 當然對于某些公司來講，一些數據是全員可見的，比如像公告、通訊錄、社區帖子等類型的數據。
系統默認權限如果需要修改，應該要受到嚴格的控制流程管理，畢竟這是整個數據權限架構中，唯一的限制。
2. 記錄所屬人
通常來說，如果一個用戶擁有某個業務實體創建對象的權限，那么針對這條特定的記錄，用戶創建完成記錄后，會自動變為這條記錄的所屬人(owner)。
在系統默認權限的基礎上，記錄的所屬人就屬于一種新增的數據權限，可以對這個用戶進行查看操作(可進行的操作應該基于基礎數據權限)。
由于業務的需要，記錄會在不同的用戶之間進行數據轉移的操作(transfer ownership)，所以記錄所屬人，不一定是記錄的創建人。
還有一種例外情況，一條記錄不屬于某個特定的用戶。
在有些公司的業務中，會有類似公海池、隊列等記錄分配器功能。
那么在分配記錄之前，這些記錄也是可以屬于這些分配器的。
相關功能的成員可以在列表視圖中看到這些分配器中的記錄數據，并進行所屬人認領的操作（更多詳細內容，我會更新在后續的公海池設計當中）。
3. 部門/相關部門
每個企業的組織架構都會區分部門，那么就有一個非常自然的需求場景：看到本部門以及下級部門相關的所有數據。
一種比較簡單的做法，就是在創建數據的時候，自動將數據關聯到創建用戶的所屬部門上。
還有一些情況，有些公司的數據是由專門的團隊負責創建的，那么針對于這些數據，就需要可以變更數據的所屬部門的能力。
隨著業務的不斷發展，可能會遇到跨部門數據查看的需求，也就是說，一個用戶有主要的所屬部門，以及根據數據權限需要而設置的多個相關部門。
4. 直屬負責人/助理
在傳統的組織架構中，除了部門層級之間的數據共享需求之外，還有人員匯報關系線。
通常的做法，就是在為每一個用戶，指定一個直屬上級負責人，直屬上級負責人會被賦予所有下屬層級的相同數據權限。
為了管理方便，也可以為直屬負責人設置助理，助理與直屬負責人具備相同的數據權限，這樣更靈活的讓不同的用戶能夠跳脫出公司組織架構的束縛。
5. 崗位層級
使用部門權限體系會帶來一個問題，企業的組織架構往往與業務的架構是不一致的。而且業務架構會經常變化，而結構變化對于數據權限控制來講，是一個挑戰。
崗位層級，可以根據數據權限需要，將一個用戶或者一組用戶放在同樣的崗位下。
這樣的話，在創建崗位的同時，也可以很好的了解公司架構到底應該以什么樣的形式組織在一起更高效。
可以從上至下的設置崗位層級，比如說最高層崗位叫CEO，可以查看整個組織的數據。然后以事業部總經理或者地區負責人的崗位，繼續向下細分，查看各自崗位下的數據。
崗位層級權限還有一個更加強大的能力，就是崗位與數據之間可以是 m:n 關系，也就是說同一條數據可以同時共享給多個崗位，滿足更加復雜的數據共享場景。
崗位層級的設計，可以將數據與用戶解綁，這在人員變動，業務調整時，可以很方便的做數據共享的變更。
6. 共享規則
對于數據權限還有一類更加接近直覺的設計方式，也就是別搞那些花里胡哨的概念，我就是要把“這一部分”數據，共享給“那一部分”人，簡單直接一點，怎么做？
換句話來講，如果上面的權限設計體系統統不能滿足業務場景，可不可以提供一種直接的數據共享方式。
“共享規則”的設計方案可能是一種解決思路。通常來講，共享規則解決了兩類場景：
- 把特定用戶的數據，共享給特定用戶。
- 把符合特定條件的數據，共享給特定用戶。
當然這里面的“特定用戶”，不僅僅只用戶本身，所有包含用戶的容器概念元素(部門、群組、角色等)，應該都包含在內。
7. 手工共享
共享規則雖然方便，但解決不了一類更要命的數據權限場景，有些共享場景是沒有辦法提前可以預想的，是隨機的，是隨時隨地的，怎么辦?
其實這種場景的前提條件就決定了權限設計的方式，既然規則不行，那就手工來指定好了。
手工共享的數據權限設計，完全是基于記錄所屬人的自由意志，記錄所屬人認為數據應該共享給誰，就共享給誰好了。
需要注意的是，當記錄的所屬關系發生變更時，那么手工共享關系應該直接解除。記錄所屬人也需要可以隨時查看和修改，當前這條數據的手工共享情況。
8. 團隊成員
手工共享的確可以解決非常態化規則的數據權限場景，但麻煩的是，共享關系會隨著記錄所屬人的所屬關系轉移，而全部丟失。
對于一條記錄來講，如果大部分需要共享的用戶不會經常發生變動，可以嘗試使用團隊成員的方式來進行手工共享。
記錄所屬人或者有記錄編輯權限的團隊成員，可以同時添加其他用戶作為這條記錄的團隊成員，記錄會對所有團隊成員共享。
這樣即使記錄所屬人發生變化，其他的團隊成員會仍然保留與此條記錄的數據共享關系。
團隊成員除了支持用戶外，也需要支持部門，群組才能更靈活的支撐單條數據的共享。
9. 群組共享
團隊成員共享方案，能夠解決大部分需要靈活配置的單條數據共享場景，但操作比較繁瑣。
如果需要頻繁共享給一個虛擬組織團隊，就需要在每一條數據上添加若干個，相同的團隊成員，效率很低。
群組就會很好地解決這個問題，若幾個用戶之間需要經常共享數據，那么可以將用戶們用群組圈起來，記錄的所屬人，可以通過將自己創建的、符合條件的數據，自動共享到若干群組中，用戶也可以通過手動共享的方式，將某條數據共享到群組中。
而只有群組成員才能看到群組中的數據，群組一般分為公用群組和私用群組。
- 公用群組是整個公司都能看到的群組，任何人都可以將數據共享到公用群組中。
- 私用群組是每個人獨立創建的，只有群組成員可以將數據共享到私用群組中。
群組應該是可以支持嵌套關系的，比如：用戶、角色、崗位、群組本身，都是可以是群組的一員。
當然處于性能的考慮，最好對類似群組套群組的這種方式，做一個層級上的限制。
群組與數據的關系應該是多對多的，也就是說，同樣一條數據，可以在不同的群組中做共享。
群組數據的共享應該是獨立的，通過類似其他崗位層級，直屬上級相關的其他權限，是無法突破群組成員限制的。也就是說UserA是群組成員，可以看到群組的數據，但UserA的上司由于不是群組成員，所以看不到群組的數據。
10. 區域層級
對于大型企業應用場景，經常會出現銷售、產品、服務分屬于不同的業務單元，但需要根據不同的規則共享客戶等相關資源。那么就可以創建多個區域層級，讓同一個客戶按照不同的層級結構共享給各個不同的業務單元。
與崗位層級類似，區域層級通常應用于地盤資源管理的數據權限劃分，通過多個不同的區域維度規則，如地區、客戶等級、行業、產品線。相應的數據在創建/編輯后，可以自動進入到符合規則的區域。
通過一些級聯跟隨分配的設置，數據下的相關數據也可以同時進入到相同區域，比如客戶下的訂單，訂單下的回款單等。
數據進入到區域后，區域成員就可以看到數據了。
一般來講，區域權限分為2級，Object、Hirerachy。
- Object 業務對象級權限，說的是一個區域成員針對于具體的業務對象，是什么權限。比如針對于客戶，是查看還是編輯?
- Hirerachy 層級權限，是說針對于業務實體，除了本級區域的權限，是否也具備下級區域的權限。
針對于單個區域，若有業務需要，也可以添加 Record 級別的權限，類似于記錄所屬人。
針對于每一個區域，也可以設置這個區域的記錄負責人（Territory Record Owner），這樣對于基于區域管理的業務屬性來講，可以將記錄做到最靈活的配置。
三、如何應用數據權限
回到最初提到的問題，他們的深層考慮是什么?
如果這條數據是我自己創建的，那么其他能看到這條數據的人都有誰?
對于很多企業來講，從數據隱私安全的角度考慮到數據權限問題，是很重要的命題。
對數據權限因果鏈條的掌握，可以對整個數據權限體系的優化，起到至關重要的指導作用。
- “小王已經從A事業部轉崗，還能通過助理權限看到B事業部的客戶呢，應該馬上取消小王的權限。”
- “小張是C事業部的銷售成員，通過群組權限看到他本應看到的客戶，而不是崗位權限看到這個客戶，看來客戶的分配邏輯有一些問題。”
有人想知道，我為什么能夠看到這條數據?
當用戶看到這條數據時，通過看到這條數據的原因，可以快速的找準自己的職責定位。
因為我是這個客戶的團隊成員，那么我需要對這個客戶的培育投入精力。
這個客戶是我下屬自拓的一名新客戶，那么我需要對其給予幫助。
更重要的是，經常的審視數據權限體系的因果關系，也會對業務本身認識得更清晰，優秀的數據權限體系，甚至可以優化公司的業務運營體系，讓效率提升自下而上的發生。
那么問題來了，既然優秀的數據權限體系，可以提升管理效率，那有沒有什么設計原則是可以遵守的？
或者說作為一個公司業務運營的管理者，到底應該怎么設計公司的數據權限體系呢?
在我們設計權限體系的時候，都是用各種概念將具體的權限，通過滿足特定業務場景的方式包裝起來。
我們把包裝起來的這樣一個個的概念，可以稱之為 “權限媒介”。
權限媒介在自身屬性上，分為三種類型：
（1）Owner
獨立媒介，比如記錄所屬人，崗位層級。
- 可以自主的滿足所有的權限結構；
- 可以包含其他權限體系。
（2）Child
子媒介，比如群組，區域。
- 可以自主的滿足所有的權限結構；
- 可以被特定的Owner媒介包含；
- 可以包含其他權限體系。
3. Element
原子媒介，比如助理/直屬上級從屬于部門層級。
- 可以理解為內部權限媒介；
- 僅可以包含其他原子媒介。
權限媒介的自身屬性類型可以幫助我們認識到，權限體系的設計是整體的，而不是混亂的。
一個媒介已經被定為成Element，就不要同時還具備Owner的屬性，不然可能雖然一時解決了問題，但今后的擴展會無比艱難。
權限媒介在使用場景上，分為兩種類型：
（1）有規則的
比如共享規則，崗位層級。
- 根據公司的業務需要，總結出來的數據共享場景；
- 可節省大量的權限共享設置成本。
（2）無規則的
比如團隊成員，手工共享。
- 人為認定的數據權限共享場景，提前無法認知；
- 規則設置成本，超過了使用成本。
權限媒介的使用場景類型，可以幫助我們認識到，權限的靈活性，要把“人”的判斷納入到整個體系中來。過高的設置成本不但會加大業務的復雜度，而且也會讓“人”失去控制感。
相信了解了權限媒介的自身屬性和使用場景之后，那我們就可以試著總結出一套適合自己公司數據權限體系架構的最佳實踐原則。
讓我們一起創造“有良好擴展性，并讓人有靈活掌控感”的數據權限體系吧。
本文由 @合理膳食與長壽 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基于CC0協議
當用戶進入到菜單中后看不到某些數據時，說明方式去提醒用戶沒有數據權限好呢？
確實有點看暈了
暈死啦
暈
有沒有初級充電書單推薦？
專業！
贊，最近剛好正在做CRM的數據權限，
已暈死，口吐白沫，不能越級看文字，我還是小白
看的暈暈乎乎的
學習中