本篇参考：

https://help.salesforce.com/s/articleView?id=sf.security_restriction_rule.htm&type=5

https://help.salesforce.com/s/articleView?id=sf.security_restriction_rule_examples.htm&type=5

https://developer.salesforce.com/docs/atlas.en-us.236.0.restriction_rules.meta/restriction_rules/restriction_rules_intro.htm

作为salesforce从业人员，数据的权限管理是一个特别重要的内容。我们熟知的设置权限的方式就是先设置 OWD进行一下 high level的设置。然后通过 Role Hierarchy / Share Rule / Manual Share进行数据权限的扩充从而达到不同的场景下，不同的USER可以扩充他可以看到的数据范围。

当然，不同的公司需求也千变万化。以下是潜在的场景需求：

• MD关系的数据，针对某个 Role的客户，只希望master类型的数据通过sharing setting进行了权限的扩充，但是detail的数据还是只能看到各自own的。因为MD关系的权限设置是 control by parent，没法去限制detail的权限，这种开发时我们只能将 detail设置成 private，然后增加很多 sharing rule或者 manual share对大部分人进行数据权限共享而只是为了忽略一小部分。
• 一个表有很多的 record type，需求是希望指定用户（比如user的某个字段）只能看到某个record type的一些数据，其他数据不支持查看（列表/report等等）

当然，demo中只列举了两个简单场景，实际场景会更多更复杂。SF的权限管理是特别厉害的，但是仍然要记住有很多限制。我们可能通过一些 workaround solution解决了，比如 sharing rule等，但是我们要知道这些都是有数量限制的，随着业务的不断变动，触发了一些government limitation以后，我们这种还是一个好的方案吗？ 现在salesforce针对这种类似的情形，增加了 restriction rule。

一. Restriction Rule概念和基础知识

简单来概括， Restriction Rule的目的是用来隐藏掉一部分基于之前的数据权限，保证满足 restriction rule的数据可以被 user看到，从而增强了salesforce的数据访问的权限。

通过上图我们可以看到这个功能很强大，当然，回想一下之前的 dynamic form / dynamic action等等强有力的功能，使用时必不可少的受制于他的 limitation，所以使用前我们需要先了解一下 restriction rule consideration。

1. classic 和lightning 都支持吗，所有的表都支持吗？

Answer: 只支持 lightning，classic环境不保证。所以如果项目是新项目，仅在 lightning下使用，那可以考虑，否则别给自己找坑。 不是所有的表都支持。

• 　　custom objects,external objects, contracts, events, tasks, time sheets, and time sheet entries

2. Restriction Rule支持哪些 Feature？ 或者说我从哪里可以直观的看到这个功能所产生的效果。

Answer: 以下的 feature 支持 Restriction Rule.

• List Views
• Lookups
• Related Lists
• Reports
• Search
• SOQL
• SOSL

这里需要提示几个注意事项，当然官方的consideration特别多，这里例举几个我们常用到的项。

• restriction rule创建以后，如果之前 search box搜索过相关的记录存在 shortcut，则search还是可以看到。如果最近浏览过记录，在 recently view的视图中还是可以看到。当然，当你点击这条记录的时候，会给你报错告诉你无法访问。
• 当user执行克隆操作时，如果这条记录的 lookup字段因为 restriction rule导致你无法访问情况下，克隆会报错。比如 order数据会关联 contract数据，如果contract因为restriction rule导致你无法访问，当你克隆 order时便会报错。
• Restriction Rule 不适用于 System Mode下代码运行的场景。
• Restriction Rule不适用于以下的这些权限场景： View All, Modify All, View All Data, and Modify All Data.
• 尽管一条记录因为 restriction rule导致了没法查看，但是我们没法通过 UserRecordAccess这个表来确定。举个例子，某个user针对一条数据拥有权限，但是restriction rule给它限制住了访问。尽管这条记录访问不到，但是 UserRecordAccess却会显示对这条数据有权限。所以后续碰到对某条记录没有权限但是 UserRecordAccess却可以展示有访问权限的场景下，可以先查询 Restriction Rule作为快速排查。

二. Demo

我们创建了一个 Demo Object的custom object，包含两个 record type: Sample 1 & Sample 2. 我们在这个表设置了一个 restriction rule，当 user的 Role为 Installation & Repair Services情况下，只能查看 Record Type 为 Sample 1的数据。

我们可以看到Demo Object的 OWD设置的是 Public Read Only.

我们创建了4条数据，两条 sample1的，两条 sample 2的，针对system admin的数据，我们可以看到4条数据。

针对demo user，设置了他的 role为 Installation & Repair Services，可以看到尽管OWD设置的是 Public Read Only，但是因为restriction rule的影响，只能看到 sample 1的数据。

这里做一下 自定义逻辑的补充，我们通过lwc组件展示restriction rule的影响。

Demo_ObjectController.cls

public with sharing class Demo_ObjectController {
@AuraEnabled(cacheable=true)
public static List getAllList() {
List demoObjectList = [SELECT Id, Name
FROM Demo_Object__c
LIMIT 50000];
return demoObjectList;
}
}

demoObjectList.html

demoObjectList.js

import { LightningElement, track, wire } from 'lwc';
const columns = [
{ label: 'Name', fieldName: 'Name', type: 'text' }
];
import getAllList from '@salesforce/apex/Demo_ObjectController.getAllList';
export default class demoObjectList extends LightningElement {
columns = columns;

@track datas;

@wire(getAllList)  
getAllList({ error, data }) {  
    if(data) {  
        this.datas = data;  
    } else if(error) {  
        //TODO  
        console.log(JSON.stringify(error));  
    }  
}  

}

通过demo user访问以后的效果：

with sharing是遵循 restriction rule的

将代码改成 without sharing，会发现所有的数据都可以搜索出来。

我们再用 UserRecordAccess这个表进行一下验证。

尽管UI上demo user访问不了sample 2的数据(下图是管理员用户查看的数据)

但是通过UserRecordAccess是可以访问到的。（下图是demo user id进行的查询展示）

这个其实是一个很危险的行为，不知道后续salesforce是否会增强。因为后续我们自定义的list view如果使用了 without sharing并且进行一些filter，结果集可能获取到的是超过restriction限制的数据，因为code的SOQL是 system mode， restriction rule没法生效。结果集搜索出来点击跳转到详情可能 list展示了，但是点击报错，用户行为极其不友好，并且没法通过 UserRecordAccess去实际的判断是否拥有权限，所以如果项目中有用到 restriction rule情况并且有自定义 list view，建议先将 restriction rule的条件和过滤的结果集也在后台看着过滤一下，避免造成不必要的影响。

总结：从功能来看，restriction rule对于权限控制又提升了特别多，也可以优化很多曾经各种绕来绕去的设计（针对一小部分特殊user的特殊访问）。使用前多看一下 consideration多测试。篇中有错误地方欢迎指出，有不懂欢迎留言。