Salesforce Flow 设计

为什么需要这个技能

在 Salesforce 生态里，Flow 被广泛用来连接业务流程，但开发者很容易踩几个隐蔽的坑：比如用 Flow 实现本该由 Formula Field 或 Validation Rule 完成的轻量逻辑，反而增加维护成本；在循环里执行 DML 或 Get Records，触发 governor limit 异常；缺少 fault connector 导致运行时错误直接暴露给用户；或者多条自动化规则在同一对象上重叠，引发执行顺序混乱甚至无限递归。这些问题在小规模测试中往往不会暴露，一旦数据量或用户量上来就会酿成线上事故。

技能的核心能力

这个技能把 Flow 的设计和验证拆成七个可执行的步骤，每一步都对应一个明确的检查点。

1. 工具匹配检查：先用一张对照表确认 Flow 是不是当前需求的正确工具。Formula Field 能搞定字段计算就不要用 Flow；Validation Rule 能拦住脏数据就不要做复杂的 before-save 逻辑；当需求涉及 callouts、多对象联动或高并发时，应该转向 Apex 而不是 Flow。
2. Flow 类型选择：根据触发时机和操作范围选择 Before-save、After-save、Screen Flow、Autolaunched、Scheduled 或 Platform Event-Triggered。核心决策原则很简单：只改当前记录字段就用 before-save，一旦需要操作关联记录、发邮件或调外部接口，就必须切到 after-save。
3. 批量安全清单：重点排查两个高频反模式——在循环里执行 Create/Update/Delete Records，以及在循环里调用 Get Records。正确做法是先把记录收集到集合变量，再把 DML 或查询放到循环外面；当目标是重塑集合结构时，优先使用 Transform 元素而不是 Loop + Assignment。
4. 容错路径要求：所有可能失败的元素都必须接上 fault connector，包括 DML、Send Email、HTTP Callout、Apex Action 和 Subflow。fault 处理路径不能回连到出错的同一个元素，否则会产生无限循环。
5. 自动化密度检查：部署前确认同一对象上没有与其他 Record-Triggered Flow、Process Builder、Workflow Rule 或 Apex Trigger 在相同触发事件上重叠。单对象超过三条自动化规则时，执行顺序风险显著增加。
6. Screen Flow UX 准则：所有分支路径都必须抵达 End 元素，多步流程要提供 Back 导航，用户输入必须使用 lightning-input 等 SLDS 兼容组件，必填项要通过屏幕级验证规则拦截。
7. 部署安全策略：永远先以 Draft 状态部署，在沙箱里用与生产等价的入口条件做全路径测试。Scheduled Flow 上线前要在沙箱跑小批量验证，Record-Triggered Flow 要确认 ISCHANGED() 等入口条件能被测试数据真正触发。

适用边界

这个技能面向的是在 Salesforce 平台中设计、构建或审查 Flow 的开发者和管理员，不替代对 Apex、Platform Events 等底层机制的理解。它能帮助团队在代码合并前拦截一类结构性问题，但无法覆盖所有运行时边缘情况。当业务逻辑本身存在歧义，或者需求边界没有被清晰定义时，依然需要人来做出架构判断。