salesforce-flow-design
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseSalesforce Flow Design and Validation
Salesforce Flow 设计与验证
Apply these checks to every Flow you design, build, or review.
你设计、构建或审核的每一个 Flow 都需要应用以下检查项。
Step 1 — Confirm Flow Is the Right Tool
步骤 1 —— 确认 Flow 是最合适的工具
Before designing a Flow, verify that a lighter-weight declarative option cannot solve the problem:
| Requirement | Best tool |
|---|---|
| Calculate a field value with no side effects | Formula field |
| Prevent a bad record save with a user message | Validation rule |
| Sum or count child records on a parent | Roll-up Summary field |
| Complex multi-object logic, callouts, or high volume | Apex (Queueable / Batch) — not Flow |
| Everything else | Flow ✓ |
If you are building a Flow that could be replaced by a formula field or validation rule, ask the user to confirm the requirement is genuinely more complex.
在设计 Flow 之前,先验证是否可以用更轻量的声明式选项解决问题:
| 需求 | 最佳工具 |
|---|---|
| 计算无副作用的字段值 | Formula field |
| 阻止错误记录保存并向用户返回提示信息 | Validation rule |
| 对父级关联的子记录进行求和或计数 | Roll-up Summary field |
| 复杂的多对象逻辑、外部调用或高负载场景 | Apex (Queueable / Batch) —— 不适用 Flow |
| 其他所有场景 | Flow ✓ |
如果你正在构建的 Flow 可以被 formula field 或 validation rule 替代,请询问需求方确认需求确实有更高的复杂度。
Step 2 — Select the Correct Flow Type
步骤 2 —— 选择正确的 Flow 类型
| Use case | Flow type | Key constraint |
|---|---|---|
| Update a field on the same record before it is saved | Before-save Record-Triggered | Cannot send emails, make callouts, or change related records |
| Create/update related records, emails, callouts | After-save Record-Triggered | Runs after commit — avoid recursion traps |
| Guide a user through a multi-step UI process | Screen Flow | Cannot be triggered by a record event automatically |
| Reusable background logic called from another Flow | Autolaunched (Subflow) | Input/output variables define the contract |
Logic invoked from Apex | Autolaunched (Invocable) | Must declare input/output variables |
| Time-based batch processing | Scheduled Flow | Runs in batch context — respect governor limits |
| Respond to events (Platform Events / CDC) | Platform Event–Triggered | Runs asynchronously — eventual consistency |
Decision rule: choose before-save when you only need to change the triggering record's own fields. Move to after-save the moment you need to touch related records, send emails, or make callouts.
| 使用场景 | Flow 类型 | 核心限制 |
|---|---|---|
| 在记录保存前更新同一条记录的字段 | Before-save Record-Triggered | 无法发送邮件、发起外部调用或修改关联记录 |
| 创建/更新关联记录、发送邮件、发起外部调用 | After-save Record-Triggered | 在提交后运行——需避免递归陷阱 |
| 引导用户完成多步骤 UI 流程 | Screen Flow | 无法被记录事件自动触发 |
| 可被其他 Flow 调用的可复用后台逻辑 | Autolaunched (Subflow) | 通过输入/输出变量定义调用约定 |
从 Apex | Autolaunched (Invocable) | 必须声明输入/输出变量 |
| 基于时间的批量处理 | Scheduled Flow | 在批量上下文下运行——需遵守治理限制 |
| 响应事件(Platform Events / CDC) | Platform Event–Triggered | 异步运行——最终一致性 |
决策规则:当你仅需要修改触发记录自身的字段时选择 before-save 类型。当你需要操作关联记录、发送邮件或发起外部调用时,切换为 after-save 类型。
Step 3 — Bulk Safety Checklist
步骤 3 —— 批量安全检查清单
These patterns are governor limit failures at scale. Check for all of them before the Flow is activated.
以下模式在规模化运行时会触发治理限制报错,在 Flow 激活前请检查所有项。
DML in Loops — Automatic Fail
循环内使用 DML —— 自动不通过
Loop element
└── Create Records / Update Records / Delete Records ← ❌ DML inside loopFix: collect records inside the loop into a collection variable, then run the DML element outside the loop.
Loop element
└── Create Records / Update Records / Delete Records ← ❌ DML inside loop修复方案:在循环内将记录收集到集合变量中,然后在循环外部运行 DML 元素。
Get Records in Loops — Automatic Fail
循环内使用 Get Records —— 自动不通过
Loop element
└── Get Records ← ❌ SOQL inside loopFix: perform the Get Records query before the loop, then loop over the collection variable.
Loop element
└── Get Records ← ❌ SOQL inside loop修复方案:在循环之前执行 Get Records 查询,然后遍历集合变量。
Correct Bulk Pattern
正确的批量模式
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 operationGet Records —— 一次查询收集所有需要的记录
└── 遍历集合变量
└── 判定 / 赋值(无 DML,无 Get Records 操作)
└── 循环结束后:创建/更新/删除记录 —— 一次 DML 操作Transform vs Loop
Transform vs 循环
When the goal is reshaping a collection (e.g. mapping field values from one object to another), use the Transform element instead of a Loop + Assignment pattern. Transform is bulk-safe by design and produces cleaner Flow graphs.
当目标是重塑集合(例如将字段值从一个对象映射到另一个对象)时,使用Transform元素替代循环+赋值的模式。Transform 天生符合批量安全要求,且生成的 Flow 结构更清晰。
Step 4 — Fault Path Requirements
步骤 4 —— 故障路径要求
Every element that can fail at runtime must have a fault connector. Flows without fault paths surface raw system errors to users.
每个可能在运行时失败的元素都必须配备故障连接器。没有故障路径的 Flow 会将原始系统错误直接暴露给用户。
Elements That Require Fault Connectors
需要配备故障连接器的元素
- Create Records
- Update Records
- Delete Records
- Get Records (when accessing a required record that might not exist)
- Send Email
- HTTP Callout / External Service action
- Apex action (invocable)
- Subflow (if the subflow can throw a fault)
- Create Records
- Update Records
- Delete Records
- Get Records(当访问可能不存在的必填记录时)
- Send Email
- HTTP Callout / 外部服务操作
- Apex 操作(可调用的)
- 子流(如果子流可能抛出故障)
Fault Handler Pattern
故障处理模式
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)Never connect a fault path back to the same element that faulted — this creates an infinite loop.
故障连接器 → 记录错误(在日志对象上创建记录或触发 Platform Event)
→ 展示友好提示信息的屏幕元素(Screen Flows 适用)
→ 停止/结束元素(Record-Triggered Flows 适用)绝对不要将故障路径连接回触发故障的同一个元素——这会造成无限循环。
Step 5 — Automation Density Check
步骤 5 —— 自动化密度检查
Before deploying, verify there are no overlapping automations on the same object and trigger event:
- Other active Record-Triggered Flows on the same +
ObjectcombinationWhen to Run - Legacy Process Builder rules still active on the same object
- Workflow Rules that fire on the same field changes
- Apex triggers that also run on the same /
before insertcontextafter update
Overlapping automations can cause unexpected ordering, recursion, and governor limit failures. Document the automation inventory for the object before activating.
在部署前,确认同一个对象和触发事件上不存在重叠的自动化:
- 同一个+
对象组合下的其他已激活记录触发流运行时机 - 同一个对象上仍处于激活状态的旧版 Process Builder 规则
- 会在相同字段变更时触发的 Workflow Rules
- 同样在/
before insert上下文下运行的 Apex 触发器after update
重叠的自动化会导致执行顺序异常、递归和治理限制报错。在激活前请整理并记录该对象的所有自动化清单。
Step 6 — Screen Flow UX Guidelines
步骤 6 —— Screen Flow UX 指南
- Every path through a Screen Flow must reach an End element — no orphan branches.
- Provide a Back navigation option on multi-step flows unless back-navigation would corrupt data.
- Use and SLDS-compliant components for all user inputs — do not use HTML form elements.
lightning-input - Validate required inputs on the screen before the user can advance — use Flow validation rules on the screen.
- Handle the Pause element if the flow may need to await user action across sessions.
- Screen Flow 的每条路径都必须到达End元素——不要存在孤立分支。
- 多步骤 Flow 需要提供返回导航选项,除非返回操作会损坏数据。
- 所有用户输入都使用和符合 SLDS 规范的组件——不要使用 HTML 表单元素。
lightning-input - 在用户进入下一步前校验屏幕上的必填输入项——使用屏幕上的 Flow 校验规则。
- 如果 Flow 需要跨会话等待用户操作,请配置Pause元素。
Step 7 — Deployment Safety
步骤 7 —— 部署安全规范
Deploy as Draft → Test with 1 record → Test with 200+ records → Activate- Always deploy as Draft first and test thoroughly before activation.
- For Record-Triggered Flows: test with the exact entry conditions (e.g. — ensure the test data actually triggers the condition).
ISCHANGED(Status) - For Scheduled Flows: test with a small batch in a sandbox before enabling in production.
- Check the Automation Density score for the object — more than 3 active automations on a single object increases order-of-execution risk.
以草稿状态部署 → 单条记录测试 → 200+条记录批量测试 → 激活- 始终先以草稿状态部署,在激活前完成全面测试。
- 针对记录触发流:使用完全符合入口条件的数据测试(例如——确保测试数据确实能触发该条件)。
ISCHANGED(Status) - 针对计划流:在生产环境启用前,先在沙箱中使用小批量数据测试。
- 检查对象的自动化密度评分——单个对象上超过3个已激活自动化会提升执行顺序异常的风险。
Quick Reference — Flow Anti-Patterns Summary
快速参考——Flow 反模式汇总
| Anti-pattern | Risk | Fix |
|---|---|---|
| DML element inside a Loop | Governor limit exception | Move DML outside the loop |
| Get Records inside a Loop | SOQL governor limit exception | Query before the loop |
| No fault connector on DML/email/callout element | Unhandled exception surfaced to user | Add fault path to every such element |
| Updating the triggering record in an after-save flow with no recursion guard | Infinite trigger loops | Add an entry condition or recursion guard variable |
Looping directly on | Incorrect behaviour at scale | Assign to a collection variable first, then loop |
| Process Builder still active alongside a new Flow | Double-execution, unexpected ordering | Deactivate Process Builder before activating the Flow |
| Screen Flow with no End element on all branches | Runtime error or stuck user | Ensure every branch resolves to an End element |
| 反模式 | 风险 | 修复方案 |
|---|---|---|
| 循环内的 DML 元素 | 治理限制异常 | 将 DML 移到循环外部 |
| 循环内的 Get Records | SOQL 治理限制异常 | 在循环前执行查询 |
| DML/邮件/外部调用元素没有故障连接器 | 未处理的异常直接暴露给用户 | 为所有这类元素添加故障路径 |
| 在 after-save 流中更新触发记录且没有递归防护 | 无限触发循环 | 添加入口条件或递归防护变量 |
直接遍历 | 规模化运行时行为异常 | 先赋值给集合变量,再遍历 |
| Process Builder 与新 Flow 同时处于激活状态 | 重复执行、执行顺序异常 | 激活 Flow 前先停用 Process Builder |
| Screen Flow 的所有分支没有都指向 End 元素 | 运行时错误或用户卡在流程中 | 确保每个分支最终都到达 End 元素 |