本篇参考：
https://admin.salesforce.com/blog/2022/how-i-solved-it-bypass-validation-rules-in-flows
背景：作为系统的全局考虑，我们在设计validation rule / flow / trigger时，往往会使用Hierarchy Custom Setting来通过标签设置白名单，当有数据清洗时，可以只关注于当前的指定字段，指定逻辑的清洗。
简单的validation rule作为一个demo：Account表有一个自定义字段 SLAExpirationDate__c，需要这个字段超过custom metadata所要求的最低的默认值。
效果展示：
这种设计在实际项目中很正常，考虑到validation rule创建以后，历史数据可能有脏数据，有些可以基于逻辑进行数据清洗，有些只能数据owner进行手动操作。
我们在项目中除了本表操作以外，还可能涉及到关联表操作更新父表的情况，举个例子，当创建Event / Task / Opportunity等数据情况下，某些场景可能需要更新到Account，比如某些场景下，针对Report使用可能需要记录一些时间戳。这里进行一个简单的demo。针对Task，Task针对Account创建的第一条数据，记录时间戳到Account自定义字段： Task_First_Created_Date__c。简单的flow操作以及效果展示。
现在问题在于，针对Account的脏数据，如果SLA Expiration Date有问题，就会导致当创建Task时，会更新Account然后报错。针对创建Task的用户不一定是Account的Owner，也可能是Account Team成员，他们不希望创建Task时，因为一个仅用于时间戳的字段（仅report用）而影响到了他们实际的业务流程或者销售流程，所以我们在实际项目中还需要考虑 onetime bypass的情况，即针对Task创建更新到Account数据，不应该触发Validation Rule，只有针对Account自身数据的编辑，才需要遵循。
针对这种情况，目前想到两种可行的方案。
- 基于Hierarchy Custom Setting，先将当前User的数据插入进去，设置Disable_Validation_Rule__c为true，当流程结束以后，再将当前user的当前记录删除。以下是效果展示。
-
基于参考链接中的方式，理解起来也很容易，我们可以基于3步走。
-
目标表创建两个字段，一个Datetime类型，设置默认值为系统当前日期，一个Formula checkbox类型，使用刚创建的Datetime类型变量减去（当前日期减去几秒时间），如果结果大于0，证明允许bypass，值为true，否则不允许bypass，值为false。
Note：之所以这么设计是当前的Datetime字段，只有初始化是当前值，之后使用就会小于0，则需要走validation rule，当其他的关联表需要bypass时，设置这个Datetime字段为当前时间。之所以减去几秒时间，代表当前关联表transaction操作时间，参考链接中写的是减去5秒，实际的transaction很难超过这个时间，通常都是毫秒级别。
-
Validation Rule进行增强，只有这个formula为false才会要求执行vlaidation rule，如果为true，则bypass跳过validation。
-
Flow进行增强，设置Datetime类型为当前时间。
效果如下方gif所示。
这两种方式优缺点：
方式1优点：
- 更精确操作，避免几秒的误差导致用户误操作；
- 可以适用于批量数据的操作。
方式1缺点：
- 尽管Custom Setting属于数据层面，鉴于hierarchy custom setting的特殊性，可能出现未知的错误或者情况。频繁的插入和删除需要进行深度测试。
方式2优点：
- 简单操作并且逻辑易于理解。
方式2缺点：
- 几秒的时间不适用于批量数据的操作，容易出现偶发性错误风险，不够精确。
**总结：**本篇主要介绍了针对 validation rule的onetime bypass的两种方案，篇中的两种思路仅抛砖引玉，方案2感谢原国外作者的思路。篇中有错误地方欢迎指出，有不懂欢迎留言。有更好的实现方式欢迎讨论。