Salesforce Sharing And Visibility 零基础学习（一）基础知识篇

阅读原文时间：2023年07月14日阅读：2

本篇参考：

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的记录拥有的操作权限整理一个表格如下：

User Permission

OWD

List View show 'New'?

Can access detail he not own?

Detail show 'Edit'/'Delete' Action?(Not Owner)

Can Edit/Delete?

CRED

Private

Yes

Private

Yes

CRED

Public Read Only

Yes

No(展示Edit/Delete按钮，点击会提示权限问题)

Public Read Only

Yes

Public Read Only

No(没有权限访问这个表，列表也不展示)

CRED

Public Read/Write

Yes

Public Read/Write

Yes

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 leadShareList = new List();
for(Lead_Team__c leadTeam : (List)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的数据生成的好处有哪些呢？