salesforce零基础学习(一百三十一)Validation 一次的bypass设计

本篇参考:

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感谢原国外作者的思路。篇中有错误地方欢迎指出,有不懂欢迎留言。有更好的实现方式欢迎讨论。

posted @ 2023-09-20 20:44  zero.zhang  阅读(364)  评论(0编辑  收藏  举报