salesforce-flow-design

Salesforce Flow 设计与验证

对你设计、构建或审查的每一个 Flow 都应用以下检查。

第 1 步 — 确认 Flow 是合适的工具

在设计 Flow 之前，先确认没有更轻量的声明式方案可以解决问题：

需求	最佳工具
无副作用地计算字段值	公式字段
通过用户消息阻止错误记录保存	验证规则
在父记录上汇总或计数子记录	汇总摘要字段
复杂的多对象逻辑、callout 或高数据量	Apex（Queueable / Batch）——而非 Flow
其他所有情况	Flow ✓

如果你正在构建的 Flow 可以被公式字段或验证规则替代，请让用户确认该需求确实更复杂。

第 2 步 — 选择正确的 Flow 类型

使用场景	Flow 类型	关键约束
在记录保存前更新同一记录上的字段	保存前 Record-Triggered	无法发送邮件、发起 callout 或更改相关记录
创建/更新相关记录、发送邮件、callout	保存后 Record-Triggered	在提交后运行——避免递归陷阱
引导用户完成多步骤 UI 流程	Screen Flow	无法由记录事件自动触发
可供其他 Flow 调用的可复用后台逻辑	Autolaunched（Subflow）	输入/输出变量定义契约
由 Apex @InvocableMethod 调用的逻辑	Autolaunched（Invocable）	必须声明输入/输出变量
基于时间的批处理	Scheduled Flow	在批处理上下文中运行——遵守 Governor Limits
响应事件（Platform Events / CDC）	Platform Event–Triggered	异步运行——最终一致性

决策规则：当你只需要更改触发记录自身的字段时，选择保存前。一旦需要触及相关记录、发送邮件或发起 callout，就改用保存后。

第 3 步 — 批量安全清单

这些模式在大规模下会导致 Governor Limit 失败。在 Flow 激活前检查所有这些问题。

循环中的 DML — 直接失败

Loop element
  └── Create Records / Update Records / Delete Records  ← ❌ DML inside loop

修复方法：在循环内将记录收集到集合变量中，然后在循环外部运行 DML 元素。

循环中的 Get Records — 直接失败

Loop element
  └── Get Records  ← ❌ SOQL inside loop

修复方法：在循环之前执行 Get Records 查询，然后遍历集合变量。

正确的批量模式

Get Records — collect all records in one query
└── Loop over the collection variable
    └── Decision / Assignment (no DML, no Get Records)
└── After the loop: Create/Update/Delete Records — one DML operation

Transform 与 Loop

当目标是重塑集合（例如将字段值从一个对象映射到另一个对象）时，使用 Transform 元素，而不是 Loop + Assignment 模式。Transform 在设计上就是批量安全的，并且会生成更简洁的 Flow 图。

第 4 步 — 故障路径要求

每个在运行时可能失败的元素都必须有故障连接器。没有故障路径的 Flow 会向用户暴露原始系统错误。

需要故障连接器的元素

• Create Records
• Update Records
• Delete Records
• Get Records（访问可能不存在的必需记录时）
• Send Email
• HTTP Callout / External Service 操作
• Apex 操作（invocable）
• Subflow（如果该 subflow 可能抛出故障）

故障处理程序模式

Fault connector → Log Error (Create Records on a logging object or fire a Platform Event)
               → Screen element with user-friendly message (Screen Flows)
               → Stop / End element (Record-Triggered Flows)

绝不要将故障路径连接回发生故障的同一元素——这会创建无限循环。

第 5 步 — 自动化密度检查

部署前，确认同一对象和触发事件上没有重叠的自动化：

• 同一 Object + When to Run 组合上的其他活动 Record-Triggered Flow
• 同一对象上仍处于活动状态的旧 Process Builder 规则
• 在同一字段更改时触发的 Workflow Rules
• 同样在相同 before insert / after update 上下文中运行的 Apex 触发器

重叠的自动化可能导致意外的执行顺序、递归以及 Governor Limit 失败。在激活前，记录该对象的自动化清单。

第 6 步 — 屏幕流 UX 指南

• 屏幕流中的每条路径都必须到达 End 元素 — 不允许存在孤立分支。
• 在多步骤流程中提供 Back 导航选项，除非返回导航会损坏数据。
• 所有用户输入均使用 lightning-input 和符合 SLDS 的组件 — 不要使用 HTML 表单元素。
• 在用户可以继续之前，先在屏幕上验证必填输入 — 使用屏幕上的 Flow 验证规则。
• 如果流程可能需要跨会话等待用户操作，请处理 Pause 元素。

第 7 步 — 部署安全

Deploy as Draft    →   Test with 1 record   →   Test with 200+ records   →   Activate

• 始终先以 Draft 形式部署，并在激活前进行全面测试。
• 对于记录触发流：使用精确的入口条件进行测试（例如 ISCHANGED(Status) — 确保测试数据确实会触发该条件）。
• 对于计划流：先在沙盒中用一小批数据进行测试，然后再在生产环境中启用。
• 检查对象的自动化密度评分 — 单个对象上超过 3 个活动自动化会增加执行顺序风险。

快速参考 — 流反模式摘要

反模式	风险	修复
循环内的 DML 元素	调控器限制异常	将 DML 移到循环外
循环内的 Get Records	SOQL 调控器限制异常	在循环前查询
DML/电子邮件/标注元素上没有故障连接器	未处理异常暴露给用户	为每个此类元素添加故障路径
在保存后流中更新触发记录且没有递归防护	无限触发器循环	添加入口条件或递归防护变量
直接对 $Record 集合进行循环	规模化时行为不正确	先赋值给集合变量，然后再循环
Process Builder 仍与新 Flow 同时处于活动状态	双重执行、意外的执行顺序	在激活 Flow 之前停用 Process Builder
屏幕流在所有分支上都没有 End 元素	运行时错误或用户卡住	确保每个分支都解析到 End 元素