Salesforce Sharing And Visibility 零基礎學習（一）基礎知識篇

• 2020 年 2 月 18 日
• 筆記

本篇參考：

https://trailhead.salesforce.com/en/users/strailhead/trailmixes/architect-sharing-and-visibility

http://resources.docs.salesforce.com/210/10/en-us/sfdc/pdf/sharing_architecture.pdf

Salesforce作為一個出色的Saas平台，絕不是僅僅因為其推出了classic / lightning的各種開發的框架和語言，所以我們作為開發者來說不應該僅僅的局限於vf / aura / lwc的開發，而是更多的去了解掌握其所自帶的標準的功能，許可權管理以及一些paas。本篇主要講述一些關於Salesforce常用的 Sharing 以及 Visibility的知識。感興趣Sharing 的可以查看上方官方的提供的pdf文檔，有時間的可以做一下上面的sharing-and-visibility的trailmix。本篇屬於基礎知識篇，講的內容可能會較散，拋磚引玉。

這張圖在很多地方大家都能看到，salesforce的sharing的架構圖。我們挑常用的進行描述。

一. (View All | Modify All) VS (View All Data | Modify All Data)

當我們在創建一個Profile時，會有很多細節的許可權控制，其中 View All Data | Modify All Data代表著這個Profile對應的user對系統中所有的對象擁有的View 以及Modify的許可權，如果我們希望某些user擁有類似管理員的許可權或者System Read Only的許可權，可以設置這兩個 View All Data | Modify All Data。

View All | Modify All 是針對具體的表進行的設置，我們有時需要類似某個表的delegation admin的許可權，希望他可以忽略sharing rule / sharing setting可以查看到或者編輯到某個表的所有數據，這個時候我們只需要針對這個 profile 的這個表許可權設置 View All | Modify All即可。

二. Org-Wide Defaults（OWD）

需要注意的是，Org-Wide Defaults 是唯一的一個方式來限制用戶的記錄訪問。怎麼可以更好的理解呢，比如一個系統中除了一個人以外，其他人對所有opportunity都有read only許可權，那我們默認需要設置的Org-Wide Defaults針對Opportunity應該為 Private 而不是 Read Only,因為 Org-Wide Defaults是唯一的方式去限制用戶記錄訪問，如果設置成了Read Only，則沒有其他的方式去限制那個人的針對Opportunity的記錄訪問。所以 Org-Wide Defaults我們設置某個表的訪問許可權時應該考慮最小的許可權的人的記錄訪問許可權應該是什麼。 Org-Wide Defaults 也對我們的許可權進行了範圍的設定。通過上面的圖我們可以知道Profile針對一個表可以設置 Read / Create /Edit /Delete / View All / Modify All。上圖中我們設置了 Accounts擁有了CRUD的許可權，如果我們在Org-Wide Defaults中對Accounts設置的Sharing Setting是 read-only，代表著這個Profile的用戶可以訪問到系統中的所有的Accounts，然而只有他Own的或者只有通過其他sharing工具賦予給他Edit/ Delete許可權的記錄他才可以操作，其他的他只擁有Read記錄的許可權，因為 Org-Wide Defaults設置的是 read-only，儘管他對 Account這個表擁有CRUD許可權，不代表他對所有的記錄都可以為所欲為。同樣的，如果系統中Org-Wide Defaults 對 Accounts設置了 Public Read/ Write許可權，但是 Profile針對 Account只有 Read/ Create許可權，他同樣沒法Edit所有的記錄，因為這個 Profile沒有Edit許可權。

設置 Org-Wide Defaults我們只需要 Set Up處搜索 Sharing Settings即可。下圖中我們可以看到有幾列內容資訊，其中Default Internal Access 代表著針對內部用戶的默認的訪問許可權，Default External Access代表著針對 Portal Community用戶的記錄訪問許可權，要求是針對外部用戶的訪問許可權一定要比內部的訪問許可權嚴格或者持平，不能外部超過內部。學習可查看此影片：http://salesforce.vidyard.com/watch/4I62yWd-0q-wpv2qR3hyKQ

設置許可權可以設置以下的幾個選項：

• Private: 只有owner和管理員以及授予了對此紀錄讀或者寫許可權的人可以訪問到此條記錄，否則沒有許可權訪問到這條數據；
• Public Read Only: 所有人都能看到這條數據，只有owner以及管理員可以修改
• Public Read/Write: 所有人都能看到和修改這條數據。
• Controlled By Parent: 此種針對master-detail具有父子關係的，用戶對父擁有什麼，對子就擁有什麼數據許可權。比如對某條Account擁有Edit許可權，則對他對應的Contact也擁有Edit許可權。

詳細的訪問許可權的描述可以參考：https://help.salesforce.com/articleView?err=1&id=sharing_model_fields.htm&type=5

我們針對Profile對某個表擁有的許可權以及Organization-Wide Defaults許可權設置和不是他own的記錄擁有的操作許可權整理一個表格如下：

Grant Access Using Hierarchies這一列用來設置數據方式是否遵循 Role Hierarchy中，勾選的情況下數據遵循Role Hierarchy原則，即如果作為當前用戶的經理或者領導級別（Role Tree上層）可以看到並且操作他的數據，只要勾選以後不需要其他的任何的配置是自動擁有這個功能的。針對敏感的數據，有些可能要求只能數據的owner以及管理員可以看到訪問數據，這種情況下就需要將這個表的Grant Access Using Hierarchies 反選掉。

三. Profile & Permission Set

Profile & Permission Set 用於控制object-level的數據安全，通過用戶可以看到什麼類型的數據並且是否他們可以對數據進行CRUD來決定。 一個用戶只能擁有一個Profile，但是相同的Profile的不同用戶針對不同的表可能有細微的訪問的區別，所以這個時候需要用到 Permission Set。一個user可以有多個 Permission Set來增強訪問。 Profile常用設置以下的許可權（可以設置的選項太多，自行查看）：

• Object CRUD View All / Modify All許可權；
• Object Field Level Security的設定；
• VF Page & Apex Class的security設定；
• Login Hour & IP Range；

Permission Set可以設置大部分 Profile設置項，但是不是所有的項 Permission Set都能搞定，所以有些項目可能只是基於 Permission Set進行管理而不是 Profile，需要先確定一下 Permission Set是否可以支援，比如 Permission Set不支援 Login Hour & IP Range。

四. Owner

一條記錄會有created by，也會有owner。Created By 是記錄的創建人，誰創建Created by 就是誰，無法更改。 Owner 默認是創建者，但是可以進行更改。Owner可以在程式中修改，針對 lead/case也可以使用assignment rule去設置。Owner可以是一個User，也可以是一個queue，這個我們可以在lead/case assignment rule選擇owner便可以看出來owner不僅僅只可以是一個user。 一條記錄的owner可以進行manual share給其他人。Sharing Rule也可以基於owner去進行數據的share。所以 Owner概念的理解對Sharing Rule 以及 Manual Share有至關重要的作用

五. Sharing Rule

當OWD設置完以後，如果針對特殊的share場景，owner可以進行manual share，但是如果share的數據量過多或者有規律可循的，我們可以使用Sharing Rule進行設置，Sharing Rule 有兩個類型，一個是Ownership-based Sharing Rule，另外一個是 Critia-based Sharing Rule，這兩種根據不同的場景使用不同的類型。入口均為Set Up處搜索 sharing settings 然後切換到某個具體的object以後，在Sharing Rule區域點擊new即可。

在第二步我們可以選擇owner-based還是criteria-based，下圖demo中是基於owner-based，當lead這條記錄的owner在清洗一組 Group情況下則會自動share給Group為清洗二組的用戶，share的許可權為Read。 Owner 除了可以選擇Group以外，還可以選擇Role/ Territory以及相關的選項。Criteria和Owner的區別為條件為當表中的欄位滿足什麼情況下share給某個群組用戶，比如當 Lead的品質較高情況下，share給sales operation團隊去進行追蹤。

需要注意的是，當share rule改變以後，原有的share關係便會移除，Salesforce在share關係理論上是讀取 __Share表,不管是sharing rule還是manual share或者程式碼層面的寫法都是生成 __Share表記錄，比如針對 Lead表的share關係，會存儲成 Lead__Share表去關聯某個錶針對某個group或者某個user擁有什麼樣的訪問許可權，當關係改變，Lead__Share相關記錄也會自動移除。

六. Account/Opportunity/Case Team & 自定義表的team

在CRM中，一個大的客戶一個大的業務機會通常由一個團隊去協同合作最終去實現贏單，這個時候便有了team的概念。在salesforce中，account team以及opportunity team是經常用到的兩個內容。

account / opportunity的owner通常可以添加一個或者多個人作為團隊成員，針對某個account / opportunity 分配給他們不同的角色以及對數據的不同的訪問許可權。從而實現這些成員可以對這個account/opportunity進行操作和追蹤。當然，這個理論上還是生成了 __Share的記錄。 account/ opportunity team在salesforce中是一個related list存在於 account/opportunity級聯列表。如果在account/opportunity找不到需要先將page layout中的級聯列表拖出來。當然，大前提是salesforce 系統中已經enable account team，詳情可以參看前面講過的sales cloud的章節。

有時項目中會用到其他表的team概念，比如 Lead Team，這個時候我們只需要按照account team去copy一下新建一個 Lead_Team__c的表即可。 當新建一條Lead_Team__c數據關聯一個user以後，程式碼生成一條 Lead__Share，說明一下RowCause即可。程式碼簡單參考如下：

if(Trigger.isAfter && (Trigger.isInsert || Trigger.isUpdate)) {      List<LeadShare> leadShareList = new List<LeadShare>();      for(Lead_Team__c leadTeam : (List<Lead_Team__c>)Trigger.new) {          LeadShare sharedLead = new LeadShare();          sharedLead.LeadId = leadTeam.Lead__c;          sharedLead.LeadAccessLevel = leadTeam.Lead_Access__c == 'Read/Write' ? 'Edit' : 'Read';          sharedLead.RowCause = 'Manual';          sharedLead.UserOrGroupId = leadTeam.User__c;          leadShareList.add(sharedLead);      }      insert leadShareList;  }

程式碼生成的和Share的數據生成的好處有哪些呢？

• 便於開發人員去追蹤和追蹤開發相關的share的問題；
• 當owner或者其他條件改變以後，程式碼生成的share不會自動刪除。

總結：篇中只是掃盲的介紹了一些salesforce中的一些許可權管理以及share相關的基礎知識，關於詳細內容以及深入和加密相關的內容沒有講解，後期有機會在單獨拿出一篇講解。篇中有錯誤地方歡迎指出，有不懂歡迎留言。