用途
该技能用于在设计和审查 Salesforce Flow 时提供架构决策、Flow 类型选择、批量安全验证和故障处理标准。对每一个设计、构建或审查的 Flow 应用以下检查。
主要能力
第一步 — 确认 Flow 是合适的工具
在设计 Flow 之前，验证更轻量的声明式选项无法解决问题：
- 计算字段值且无副作用：使用公式字段
- 通过用户消息阻止错误记录保存：使用验证规则
- 对父记录的子记录求和或计数：使用汇总摘要字段
- 复杂的多对象逻辑、调用或高数据量：使用 Apex（Queueable / Batch），而非 Flow
- 其他所有情况：使用 Flow
如果正在构建的 Flow 可以被公式字段或验证规则替代，应请用户确认需求确实更复杂。
第二步 — 选择正确的 Flow 类型
- 在记录保存前更新同一记录上的字段：使用保存前记录触发 Flow，限制为不能发送邮件、进行调用或更改相关记录
- 创建/更新相关记录、发送邮件、调用：使用保存后记录触发 Flow，在提交后运行，需避免递归陷阱
- 引导用户完成多步骤 UI 流程：使用 Screen Flow，不能由记录事件自动触发
- 从另一个 Flow 调用的可复用后台逻辑：使用 Autolaunched（子流程），输入/输出变量定义契约
- 从 Apex @InvocableMethod 调用的逻辑：使用 Autolaunched（Invocable），必须声明输入/输出变量
- 基于时间的批处理：使用计划 Flow，在批处理上下文中运行，需遵守调控器限制
- 响应事件（平台事件 / CDC）：使用平台事件触发 Flow，异步运行，最终一致性
决策规则：当只需要更改触发记录自身的字段时选择保存前；一旦需要触及相关记录、发送邮件或进行调用，就应改用保存后。
第三步 — 批量安全检查清单
以下模式在大规模下会导致调控器限制失败，在 Flow 激活前需全部检查：
- 循环中的 DML：自动失败。修复方法：在循环内将记录收集到集合变量中，然后在循环外运行 DML 元素。
- 循环中的 Get Records：自动失败。修复方法：在循环前执行 Get Records 查询，然后遍历集合变量。
- 正确的批量模式：Get Records 一次查询收集所有记录 → 遍历集合变量 → 决策/赋值（无 DML、无 Get Records）→ 循环后执行一次创建/更新/删除记录 DML 操作。
- Transform 与 Loop：当目标是重塑集合（例如将字段值从一个对象映射到另一个对象）时，使用 Transform 元素而非 Loop + Assignment 模式。Transform 在设计上就是批量安全的，并产生更清晰的 Flow 图。
第四步 — 故障路径要求
每个在运行时可能失败的元素都必须有故障连接器。没有故障路径的 Flow 会向用户暴露原始系统错误。
需要故障连接器的元素：创建记录、更新记录、删除记录、Get Records（访问可能不存在的必需记录时）、发送邮件、HTTP 调用/外部服务操作、Apex 操作（invocable）、子流程（如果子流程可能抛出故障）。
故障处理模式：故障连接器 → 记录错误（在日志对象上创建记录或触发平台事件）→ 带用户友好消息的 Screen 元素（Screen Flow）→ 停止/结束元素（记录触发 Flow）。切勿将故障路径连接回出错的同一元素，否则会造成无限循环。
第五步 — 自动化密度检查
部署前，验证同一对象和触发事件上没有重叠的自动化：
- 同一对象 + 运行时机组合上的其他活动记录触发 Flow
- 同一对象上仍处于活动状态的旧版 Process Builder 规则
- 在同一字段更改时触发的工作流规则
- 也在同一 before insert / after update 上下文中运行的 Apex 触发器
重叠的自动化可能导致意外的执行顺序、递归和调控器限制失败。在激活前记录该对象的自动化清单。
第六步 — Screen Flow 用户体验指南
- Screen Flow 的每条路径都必须到达 End 元素，不能有孤立分支。
- 多步骤流程应提供返回导航选项，除非返回导航会破坏数据。
- 所有用户输入使用 lightning-input 和符合 SLDS 的组件，不要使用 HTML 表单元素。
- 在用户前进之前验证屏幕上的必填输入，使用屏幕上的 Flow 验证规则。
- 如果流程可能需要跨会话等待用户操作，需处理 Pause 元素。
第七步 — 部署安全
部署流程：作为草稿部署 → 用 1 条记录测试 → 用 200+ 条记录测试 → 激活。
- 始终先作为草稿部署，并在激活前彻底测试。
- 对于记录触发 Flow：使用确切的入口条件测试（例如 ISCHANGED(Status) — 确保测试数据确实触发该条件）。
- 对于计划 Flow：在生产环境启用前，在沙盒中用一小批数据测试。
- 检查对象的自动化密度评分 — 单个对象上超过 3 个活动自动化会增加执行顺序风险。
快速参考 — Flow 反模式摘要
- 循环内的 DML 元素：风险为调控器限制异常，修复方法是将 DML 移到循环外。
- 循环内的 Get Records：风险为 SOQL 调控器限制异常，修复方法是在循环前查询。
- DML/邮件/调用元素上没有故障连接器：风险为未处理异常暴露给用户，修复方法是为每个此类元素添加故障路径。
- 在保存后 Flow 中更新触发记录且无递归保护：风险为无限触发循环，修复方法是添加入口条件或递归保护变量。
- 直接遍历 $Record 集合：风险为大规模下行为不正确，修复方法是先赋值给集合变量再遍历。
- Process Builder 与新 Flow 同时活动：风险为双重执行、意外顺序，修复方法是在激活 Flow 前停用 Process Builder。
- Screen Flow 所有分支上没有 End 元素：风险为运行时错误或用户卡住，修复方法是确保每个分支都解析到 End 元素。
适用场景
适用于 Salesforce 管理员和开发者设计、构建或审查 Flow 时，尤其是需要确保批量安全、故障处理和部署安全性的场景。
限制
该技能为设计检查清单和规范，不提供自动化执行或代码生成功能。具体实施仍需在 Salesforce 平台中手动完成。