salesforce-flow-design

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Salesforce 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:
RequirementBest tool
Calculate a field value with no side effectsFormula field
Prevent a bad record save with a user messageValidation rule
Sum or count child records on a parentRoll-up Summary field
Complex multi-object logic, callouts, or high volumeApex (Queueable / Batch) — not Flow
Everything elseFlow ✓
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 caseFlow typeKey constraint
Update a field on the same record before it is savedBefore-save Record-TriggeredCannot send emails, make callouts, or change related records
Create/update related records, emails, calloutsAfter-save Record-TriggeredRuns after commit — avoid recursion traps
Guide a user through a multi-step UI processScreen FlowCannot be triggered by a record event automatically
Reusable background logic called from another FlowAutolaunched (Subflow)Input/output variables define the contract
Logic invoked from Apex
@InvocableMethod
Autolaunched (Invocable)Must declare input/output variables
Time-based batch processingScheduled FlowRuns in batch context — respect governor limits
Respond to events (Platform Events / CDC)Platform Event–TriggeredRuns 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
@InvocableMethod
中调用的逻辑
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 loop
Fix: 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 loop
Fix: 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 operation
Get 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
    Object
    +
    When to Run
    combination
  • 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 insert
    /
    after update
    context
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
    /
    after update
    上下文下运行的 Apex 触发器
重叠的自动化会导致执行顺序异常、递归和治理限制报错。在激活前请整理并记录该对象的所有自动化清单。

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
    lightning-input
    and SLDS-compliant components for all user inputs — do not use HTML form elements.
  • 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 需要提供返回导航选项,除非返回操作会损坏数据。
  • 所有用户输入都使用
    lightning-input
    和符合 SLDS 规范的组件——不要使用 HTML 表单元素。
  • 在用户进入下一步前校验屏幕上的必填输入项——使用屏幕上的 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.
    ISCHANGED(Status)
    — ensure the test data actually triggers the condition).
  • 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-patternRiskFix
DML element inside a LoopGovernor limit exceptionMove DML outside the loop
Get Records inside a LoopSOQL governor limit exceptionQuery before the loop
No fault connector on DML/email/callout elementUnhandled exception surfaced to userAdd fault path to every such element
Updating the triggering record in an after-save flow with no recursion guardInfinite trigger loopsAdd an entry condition or recursion guard variable
Looping directly on
$Record
collection
Incorrect behaviour at scaleAssign to a collection variable first, then loop
Process Builder still active alongside a new FlowDouble-execution, unexpected orderingDeactivate Process Builder before activating the Flow
Screen Flow with no End element on all branchesRuntime error or stuck userEnsure every branch resolves to an End element
反模式风险修复方案
循环内的 DML 元素治理限制异常将 DML 移到循环外部
循环内的 Get RecordsSOQL 治理限制异常在循环前执行查询
DML/邮件/外部调用元素没有故障连接器未处理的异常直接暴露给用户为所有这类元素添加故障路径
在 after-save 流中更新触发记录且没有递归防护无限触发循环添加入口条件或递归防护变量
直接遍历
$Record
集合
规模化运行时行为异常先赋值给集合变量,再遍历
Process Builder 与新 Flow 同时处于激活状态重复执行、执行顺序异常激活 Flow 前先停用 Process Builder
Screen Flow 的所有分支没有都指向 End 元素运行时错误或用户卡在流程中确保每个分支最终都到达 End 元素