小编点评

## Summary of the Blog Post This blog post provides two possible solutions to address one-time bypass issues with validation rules in Salesforce Flows: **Solution 1: Disable Validation Rule for One Time** * Use a hierarchy custom setting to configure whitelisting for the specific field. * During the flow creation, set `Disable_Validation_Rule__c` to `true`. * After the flow execution, delete the current user's record from the custom setting. * This approach ensures only edits within the specific field are validated, preventing the validation rule from triggering. **Solution 2: Implement One-Time Bypass Logic** * Define two fields in the target object: * `Datetime`: Set the default value to the current system date. * `Formula`: Use the created date minus a specified number of seconds (5 seconds in the provided example). * Use a validation rule to enforce bypass only when the formula evaluates to `false`. * Enhance the flow to use the `Datetime` field with a formula. **Additional Notes:** * Both solutions achieve the same goal, but **Solution 1 is more precise and can handle bulk operations efficiently** due to its ability to perform updates within the custom setting. * **Solution 2 is simpler to implement but may have limitations for bulk operations** due to the time calculation being performed within a formula. * The provided solutions offer a good balance between precision and ease of implementation. * Consider the specific requirements of your use case and choose the solution that best fits your needs.

正文

本篇参考：

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自身数据的编辑，才需要遵循。

 针对这种情况，目前想到两种可行的方案。

1. 基于Hierarchy Custom Setting，先将当前User的数据插入进去，设置Disable_Validation_Rule__c为true，当流程结束以后，再将当前user的当前记录删除。以下是效果展示。

 2. 基于参考链接中的方式，理解起来也很容易，我们可以基于3步走。

1. 目标表创建两个字段，一个Datetime类型，设置默认值为系统当前日期，一个Formula checkbox类型，使用刚创建的Datetime类型变量减去（当前日期减去几秒时间），如果结果大于0，证明允许bypass，值为true，否则不允许bypass，值为false。

Note：之所以这么设计是当前的Datetime字段，只有初始化是当前值，之后使用就会小于0，则需要走validation rule，当其他的关联表需要bypass时，设置这个Datetime字段为当前时间。之所以减去几秒时间，代表当前关联表transaction操作时间，参考链接中写的是减去5秒，实际的transaction很难超过这个时间，通常都是毫秒级别。

2. Validation Rule进行增强，只有这个formula为false才会要求执行vlaidation rule，如果为true，则bypass跳过validation。

3. Flow进行增强，设置Datetime类型为当前时间。

效果如下方gif所示。

这两种方式优缺点：

方式1优点：

• 更精确操作，避免几秒的误差导致用户误操作；
• 可以适用于批量数据的操作。

方式1缺点：

• 尽管Custom Setting属于数据层面，鉴于hierarchy custom setting的特殊性，可能出现未知的错误或者情况。频繁的插入和删除需要进行深度测试。

方式2优点：

• 简单操作并且逻辑易于理解。

方式2缺点：

• 几秒的时间不适用于批量数据的操作，容易出现偶发性错误风险，不够精确。

总结：本篇主要介绍了针对 validation rule的onetime bypass的两种方案，篇中的两种思路仅抛砖引玉，方案2感谢原国外作者的思路。篇中有错误地方欢迎指出，有不懂欢迎留言。有更好的实现方式欢迎讨论。