一，控制用户访问权限

1.Levels of Data Access（数据访问权限级别）

在 Salesforce 中，主要在以下四个主要级别配置数据访问权限

1. 组织（Organization）级别

最高级别，可以通过维护授权用户列表、设置密码策略（password policies）和限制某些时段和地点的登录权限来保护组织访问权限

2. 对象（Objects）级别

对象级安全性（Object–level security ）是控制用户访问权限的最简单方法。通过设定特定类型对象的权限，可以防止一组用户创建、查看、编辑或删除该对象的任何记录。

3. 字段（Fields）级别

可以使用字段级安全性（ field–level security）来限制对特定字段的访问，即使是用户可访问对象中的字段。例：可以让职位object中的工资字段对面试官不可见，但对招聘经理和招聘人员可见

4. 记录（Records）级别

为了更精确地控制数据，可以允许特定用户查看某个对象，但限制他们能看到哪些对象记录。例：记录级访问权限允许面试官查看和编辑自己的评价，但无法访问其他面试官的评价。
可以通过以下方式管理记录级访问权限（record–level access）
（1）Organization–wide defaults （组织范围默认）：设置指定用户对彼此Records的默认访问权限级别。（设置了用户非自己拥有的记录的基本访问权限级别（给出去的权限较少），再加上下面的3个权限来向需要的用户开放数据（在权限少的基础上开放点权限））

使用Organization–wide defaults将数据锁定在最高限制级别，然后使用其他共享工具选择性地授予其他用户访问权限。

例：可以允许所有员工访问“Candidate（候选人）”对象，这样任何人都可以向数据库中添加候选人，但是可以限制对“职位”的编辑权限，这样所有人都可以查看空缺的职位，但只有授权员工可以进行编辑

（2）角色层次结构（Role hierarchies）：向高级别人员开放访问权限，这样他们就可以继承对较低级别用户记录的访问权限。角色层次结构不一定与你的组织图匹配。层次结构中的各个角色代表用户或用户组所需的数据访问权限级别。

例：你可以将组织范围默认设置为“private”，但允许招聘人员查看和编辑他们自己的候选人记录，从而限制对候选人的访问。招聘人员无法查看其他人的候选人记录，因为招聘人员都处于角色层次结构中的相同级别。不过，由于招聘经理级别较高，可以授予招聘经理对所有候选人记录的读/写权限。

（3）共享规则（Sharing rules）：可以自动允许特定用户组采用例外的组织范围默认设置，使他们能够访问其他人的记录或通常情况下无法查看的记录。共享规则与角色层次结构相似，仅用于授予更多用户对记录的访问权限，它们不应比你的组织范围默认设置更严格。

例：可以允许所有员工查看职位，但使用共享规则将完全编辑权限授予那些“招聘经理”角色或组别中的员工

共享规则类型（Sharing Rule Types）
（3）-1.Owner-Based Sharing Rules(基于所有人的共享规则)：基于所有人的共享规则打开对特定用户所有记录的访问权限。

例如，公司的销售经理需要查看由不同区域的销售经理所有的业务机会。通过基于所有人的共享，美国销售经理会授予 APAC 销售经理对美国团队所有业务机会的访问权限。

（3）-2.Criteria-Based Sharing Rules（基于条件的共享规则）：基于条件的共享规则根据字段值决定与谁共享记录。

例如，你使用作业应用程序的自定义对象，并拥有名为“部门”的自定义选项列表字段。一个基于条件的共享规则可与你的组织中的所有 IT 管理员共享“部门”字段设为“IT”的所有作业应用程序。

*注意

• 无法使用 Apex 创建基于条件的共享规则。而且，无法使用 Apex 测试基于条件的共享。
• 基于条件的共享规则取决于记录值，而不是记录所有人。角色或区域层次结构仍允许层次结构中较高的用户访问记录。
• 从 API 版本 24.0 开始，可以使用元数据 API SharingRules 类型，以创建基于条件的共享规则。
• 可为accounts, assets, campaigns, cases, contacts, leads, opportunities, work orders, 和自定义对象创建基于条件的共享规则。
• 文本和文本区对大小写敏感。例如，在文本字段中指定“Manager”的基于条件的共享规则不会共享字段中为“manager”的记录。要创建具有词语的多个通用情形的规则，输入每个值，用逗号隔开。

（3）-3.Guest User Sharing Rules(来宾用户共享规则)：来宾用户共享规则是一种特殊类型的基于标准的共享规则，也是向未经身份验证的来宾用户授予记录访问权限的唯一方式。

来宾用户共享规则类型向没有登录凭据的来宾用户授予访问权限。通过创建来宾用户共享规则，允许任何人立即无限制地访问所有符合共享规则标准的记录。
为了保护 Salesforce 数据并让你的来宾用户能够访问他们需要的内容，需要考虑创建这种类型的共享规则的所有用例和含义。
（4）手动共享（Manual sharing）：允许特定记录的所有者与其他用户共享特定记录。尽管手动共享不像组织范围共享设置、角色层次结构或共享规则一样自动化，但在某些情况下非常有用

例如，当一名正在度假的招聘人员需要将某个职位申请的所有权临时分配给其他人时

注意
平台中的两个重要概念：
1. 始终根据对象级、字段级和记录级权限的组合来评估记录的权限。
例如：创建了名为“招聘人员”的Profile（为招聘人员创建对象级权限）。并且限制此profile对招聘相关object（例如“职位”或“候选人”）的删除权限，但即使你授权招聘人员创建、读取或编辑招聘对象，也不一定意味着招聘人员可以读取或编辑所有招聘对象记录，例如单个职位或候选人。
2. 在对象级别权限与记录级别权限出现冲突时，以最严格的设置为准。
这意味着，即使你对profile授予招聘object的创建、读取和编辑权限，如果单个招聘记录的记录级权限更严格，则这些权限即是定义招聘人员可以访问的内容的规则。
例如，如果你授予“招聘人员”profile对“候选人”object的创建、读取和编辑权限，但只允许招聘人员访问他们自己的“候选人”记录，那么招聘人员就只能访问各自的记录。

2.确定你的App所需的Organization–wide defaults

首先需要明确下面三个问题：

1. 哪个用户是该对象最想限制的用户？
2. 该对象中是否会有此用户不可以查看的实例？
3. 该对象中是否会有此用户不可以编辑的实例？
   

字段	描述
专用	仅记录所有人和更高级别的用户可以查看、编辑和报告这些记录(可以通过设置角色层次结构或定义共享规则来授予用户更多的记录访问权限。不过，只能使用共享规则授予更多访问权限，不可增加对记录的访问权限的限制)
公用只读	所有用户可以查看和报告记录，但无法编辑。仅记录所有人和更高级别的用户可以编辑这些记录。(可以通过设置角色层次结构或定义共享规则来授予用户更多的记录访问权限。不过，只能使用共享规则授予更多访问权限，不可增加对记录的访问权限的限制)
公用读/写	所有用户可以查看、编辑和报告所有记录。
由父级控制	用户可以根据是否可对联系人相关记录执行特定操作来判断是否能对该联系人执行相同的操作（例如查看、编辑或删除）

二，Permission Set

1.Permission Set Groups概要

当权限集组重新计算时，分配的用户保留上次完成重新计算时的权限。
当组中的某个权限集发生了变化，将开始重新计算权限集，触发权限集组重新计算的更改，包括：

• Changing existing permission sets
• Adding permission sets
• Removing permission sets

权限集组的状态显示在“权限集组”列表视图页面的“状态”列中。
有效状态包括“更新”、“过期”、“更新”和“失败”。
设计图：

注意：就像权限集一样，如果用户的许可证不允许你想要分配的权限，则不能将用户分配到权限集组。

2.Permission Helper App（第三方应用）

Permission Helper App
权限分配分析可能需要一些时间。在AppExchange上可用的权限助手应用程序可以提供帮助。助手应用程序可以帮助查看用户拥有什么权限，将一些配置文件转换为权限集，等等。例如，你可能想从现有的配置文件中获取权限，然后使用应用程序将它们转换为权限集。

3.Mute Permissions in Permission Set Groups

可以在一个权限集组中给某些个权限集中的某些权限mute掉
下面举例说明：在【sales processing】这个Permission Set Groups里，将【contracts processing】权限集中的浅蓝色部分的权限给禁掉，只是属于这个组的人没有该权限或者说不能使用该权限，但是，【contracts processing】权限集中的用户可以继续使用这些权限

4.Muting and Permission Dependencies

静音和权限依赖：注意：当静音权限时，需要注意权限依赖关系。

例如，假设授予所有用户对一个对象的“创建”、“读取”、“编辑”和“删除”权限。然后为该对象授予一些用户“查看全部”和“修改全部”。现在，如果静音了“读取”权限，“创建”、“编辑”、“删除”、“查看全部”和“修改全部”也会被静音，因为如果没有读取数据的能力，用户就无法执行这些任务。

这个例子相当简单，但是依赖关系可能会很复杂。当静音权限时，一定注意在保存更改时注意权限更改确认消息。
如下图，在静音销售契约权限集中的权限时，如果已经静音了激活契约，那么删除激活契约也将被静音。

三，几个重要权限的区别

（1）Profiles ：为每个用户提供默认设置，如默认record type、 IP range等。是最小的访问权限。
Salesforce建议使用profile作为分配给用户的最佳实践，因为每个用户只有一个配置文件。

（2）Permission Sets：权限集是settings 和Permission 的集合。
profiles允许用户执行一些task，但是权限集允许额外的task(profile不启用的task)。

例如：可以添加权限来创建和自定义列表视图、激活contracts（契约）或任何数量的其他权限。

（3）Permission Set Groups：权限集将权限集捆绑在一起。被分配到权限集组中的用户将获得该组中所有权限集的组合权限。权限集组相当于应用户的工作功能。

四.如何在salesforce中保护你的数据（权限的组合列举）

1.Restrict Login Hours and IP Ranges

限制组织的登录时间和 IP 范围

1. 在profile中限制组织的登录时间：
   
   2.在profile中限制组织的登录IP范围
   

2.Profile and Permission Set

创建简档并设置了对象访问权限

因为profile为用户设计最基本权限，所以在此基础上为用户添加permission set

举例说明：
（1）在【Profiles】中克隆【Standard Platform User.】profile，并命名为【Standard Profile - No Acct Delete】，编辑Account object的权限，使其没有【Delete】权限

（2）创建Permission Set 【Delete Accounts】，并选择【Salesforce Platform】licence（此类用户将适用），保存之后，设定Account 的object 权限为【Delete】，注意此时【Edit】和【Read】将同时选上


（3）创建用户A，A拥有【Standard Profile - No Acct Delete】profile，并将A添加到【Delete Accounts】permission set里面，这样A就拥有了delete account 的权限了

3.Set Organization-Wide Defaultsand Create a Role Hierarchy

构建一个角色层次结构，以确保每个用户只能访问其特定角色所需的信息
创建共享规则，让用户在记录上进行协作

一般创建好新的object之后，需要到【Sharing Settings】设置Organization-Wide Defaults，本例将三个object的【Default Internal Access】设置成private

• Applicant（申请人）object
• Interviewer（面试官）object
• Position（职位）object

（1）创建sharing rule，使招聘人员之间可以共享申请人：

常见的角色层次结构：

• CEO
• VP of Services（服务副总裁）
  - Accounts Receivable（应收账款）
  - Customer Support Director（客户支持总监）
  - Customer Support Rep（客户支持代表）
• SVP, Sales & Marketing
  - VP, North American Sales
  - Director, Direct Sales（直销总监）
  - Sales Engineer（销售工程师）
• SVP, Human Resources
  - Recruiter（招聘员）