Salesforce最初建议客户应该使用“每个对象一个Flow”来设计自动化。但随着客户背景愈发广泛,客户需求愈发丰富,这些建议显然不够明确。
从技术上来说,不可能为每个对象只创建一个Record-triggered Flow。你可能需要在更新数据库之前执行许多操作,而其他操作需要在更新之后运行。因此,可能需要创建一个Before Flow和After Flow以满足业务需求。
同样,Record-triggered Flow可以在创建、更新、或删除时触发。你可以将Before Flow和After Flow配置为在创建或更新时执行,但删除需要再次单独处理。这意味着,最终每个对象可创建的Flow数量是3个:
自动化领域近期的变化
Salesforce发布了Migrate?to?Flow等工具,这些工具可以创建多个较小的Record-triggered?Flow,每个Flow对应之前拥有的每个旧自动化。如果组织中每个对象有1个Process Builder和5个Workflow Rules,则这将转换为6个新Flow。这可能会给组织留下一个以随机顺序自动启动的混乱局面,并且不会真正指导用户遵循任何特定的最佳实践或标准设计方法。
因此,Record-triggered Flow设计的两种主要方法从这些新工具和围绕Flow最佳实践的对话中诞生。
方法1:具有进入标准的多个较小Flow
Flow工具的最新增强功能在构建Record-triggered Flow时带来了一种全新的设计方法:利用Flow?Entry?Criteria功能与Flow?Trigger?Explorer结合创建多个仅包含少量功能的较小Flow,并且只有一组特定的记录会触发其运行。话虽如此,这个方法有利有弊。
优点
Flow将变得更小且更易于阅读。因此,如果需要进行更改,它们将更容易更新,找到需要进行更改的流程区域将变得更加容易。
通过Summer?'22版本中Flow?Trigger?Explorer的更新,通过新的拖放功能可以更轻松地重新排列特定对象的Flow触发顺序。该系统还将看到性能改进,特别是在具有大数据量的组织中,因为并非每个Flow都会随着每个记录操作加载到内存中,只有那些满足进入条件的Flow才会加载到内存中。
缺点
管理多个Flow意味着,如果遇到Bug或由于使用Migrate to Flow工具而继承了许多新的Record-triggered Flow,则需要搜索并深入研究多个Record-triggered Flow才能找出问题的根源。
还需要考虑某些Salesforce许可证的限制。例如,Salesforce的Professional和Essentials版本一次只允许有5个活跃的Flow。这意味着,如果有潜在客户对象的自动回复电子邮件流、个案的自动回复电子邮件流以及新联系人的欢迎电子邮件自动化,那么只能再创建两个Record-triggered Flow。
方法2:三法则
存在三种不同类型的Record-triggered Flow:
这就是三法则发挥作用的地方。如果你希望将流功能分组到尽可能少的Flow中,那么可以将其分组在一起,并在创建/更新之前、创建/更新之后或删除之前插入。话虽如此,你不需要为每个对象创建3个Flow。你应该根据业务需求进行设计。这意味着:
实际上,你不能像之前的Process Builder那样为每个对象拥有一个Flow 。因为你可能需要更新前、更新后和删除流,而这些流都必须是单独的Flow。
为每个对象添加更多Flow
从Spring '22开始,可以设置Record-triggered Flow的触发顺序。在某种程度上,“每个对象一个Flow”已经转变为“每个对象X?+?突然触发顺序”。这有助于使每个对象多个Flow成为更可行且更受欢迎的方法。
如果业务增长超出了三法则的范围,你应该将其作为一项业务进行评估,并计划一个利用进入标准和Flow触发顺序的前进方向。
从Process?Builder转向Flow
虽然单一触发条件(仅在创建/更新之前或创建/更新之后或删除之前)与Process Builder类似,但无法区分“befores”和“afters”,而在Flow中可以实现,这是一项增值巨大的功能。目前,我建议使用“rebuild and enhance”方法,而不是使用Salesforce的迁移工具来复制粘贴。
重建和增强意味着全面重新评估自动化前景,并且必然需要整个企业中多个利益相关者付出大量努力。
作者:自由侠部落
🔥🔥Salesforce学习资料、高薪岗位、考证攻略,$40考试优惠券
本文欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接
如果文章的内容对你有帮助,欢迎点赞~