精通 Salesforce Flow Builder：顾问视角下的声明式自动化指南

背景与应用场景

我是一名 Salesforce 咨询顾问。在我的日常工作中，我与各种规模和行业的客户合作，帮助他们解决复杂的业务挑战。一个反复出现的主题是“自动化”。客户希望减少手动任务，提高数据准确性，并为他们的员工和客户创造无缝的体验。在 Salesforce 生态系统中，实现这一目标的核心工具就是 Flow Builder（流程构建器）。

Salesforce 的自动化工具经历了一段漫长的演变。从最初的 Workflow Rules（工作流规则）和 Approval Processes（批准过程），到后来功能更强大的 Process Builder（流程构建器），每一步都为管理员提供了更多的能力。然而，Flow Builder，特别是其现代版本，已经成为 Salesforce 声明式（declarative）自动化的巅峰之作。它不仅整合并超越了旧工具的功能，还提供了构建复杂、交互式用户体验的能力，这是以前只有通过编写 Apex 代码才能实现的。

作为顾问，我们之所以极力推荐 Flow Builder，是因为它在“低代码”（low-code）和“无代码”（no-code）之间架起了一座完美的桥梁。它赋予了 Salesforce 管理员前所未有的强大能力，同时为开发人员提供了一个可以轻松扩展的框架。以下是我们经常为客户设计的几个典型应用场景：

场景一：引导式客户服务工单创建

业务挑战：客户服务代理在接听电话时，需要快速准确地记录客户问题。不同的问题类型（如账单问题、技术支持、产品咨询）需要收集不同的信息。

Flow 解决方案：我们可以创建一个 Screen Flow（屏幕流程）。这个流程会通过一系列屏幕引导代理。例如，第一个屏幕询问问题类型，根据代理的选择，后续的屏幕会动态显示需要填写的字段。流程可以在后台自动查询相关的客户信息、合同状态，并在最后一步创建一个格式完美的 Case（个案）记录。这不仅减少了培训时间，还确保了数据的完整性和一致性。

场景二：复杂的销售订单处理自动化

业务挑战：当一个 Opportunity（业务机会）的状态变为“Closed Won”（已成交）时，需要执行一系列复杂的操作：创建一个 Order（订单）记录，为订单生成多个 Order Line Items（订单行项目），更新相关 Account（客户）的信用等级，并向财务团队发送一个通知。

Flow 解决方案：一个 Record-Triggered Flow（记录触发流程）是完美的解决方案。当业务机会被更新并满足特定条件时（`StageName` = 'Closed Won'），流程会自动触发。它会查询业务机会下的所有产品，然后在一个循环（Loop）中为每个产品创建对应的订单行项目，最后将所有新记录一次性插入数据库，并执行更新客户记录和发送邮件通知等操作。这避免了销售人员手动创建多个关联记录，大大提高了效率。

场景三：定期的系统数据维护

业务挑战：系统中有许多超过90天未更新的 Lead（潜在客户）记录，需要定期将它们的状态更新为“Archived”（已归档），并通知其负责人。

Flow 解决方案：我们可以配置一个 Schedule-Triggered Flow（计划触发流程），让它在每周日凌晨2点运行。流程会自动查询所有符合条件的潜在客户记录，批量更新它们的状态，并向记录的所有者发送一封包含已归档潜在客户列表的电子邮件摘要。

原理说明

要有效地为客户设计 Flow 解决方案，我们必须深入理解其核心构建块。Flow Builder 是一个可视化的设计工具，我们通过拖放元素来构建逻辑。以下是其关键组成部分：

1. 流程类型 (Flow Types)

选择正确的流程类型是设计的第一步，因为它决定了流程如何被启动。

Screen Flow: 包含用户界面的流程，需要用户交互。通常嵌入到 Lightning 页面、Experience Cloud 站点或通过按钮启动。
Record-Triggered Flow: 当一个记录被创建、更新或删除时自动触发。这是替代 Process Builder 和大部分 Workflow Rules 的首选。
Schedule-Triggered Flow: 在指定的时间和频率为一批记录运行。
Platform Event-Triggered Flow: 当接收到平台事件（Platform Event）消息时启动，非常适合用于系统集成场景。
Autolaunched Flow (No Trigger): 无用户界面且不会自动触发。它必须被其他流程、Process Builder、Apex 或 API 调用。常用于构建可复用的模块化逻辑（我们称之为 Subflow）。

2. 元素 (Elements)

元素是构成流程逻辑的基本单位，可以分为三类：

交互 (Interaction): 核心是 Screen（屏幕）元素，用于向用户显示信息或收集用户输入。
逻辑 (Logic):
- Assignment (分配): 用于给变量赋值。
- Decision (决策): 根据条件创建不同的执行路径，相当于 `if-then-else` 语句。
- Loop (循环): 遍历一个记录集合（Collection）中的每一项，并对每一项执行操作。
数据 (Data): 这些元素负责与 Salesforce 数据库交互。
- Create Records (创建记录)
- Update Records (更新记录)
- Get Records (获取记录)
- Delete Records (删除记录)

3. 资源 (Resources)

资源是流程中用于存储数据的“容器”，类似于编程中的变量。它们在整个流程执行期间持有信息。

Variable (变量): 最常见的资源，可以存储文本、数字、日期、布尔值或一个完整的 Salesforce 记录。
Constant (常量): 一个固定的值，在流程运行期间不会改变。
Formula (公式): 一个在流程运行时动态计算值的表达式，类似于 Excel 或 Salesforce 中的公式字段。
Text Template (文本模板): 用于构建格式化的文本块，可以包含变量和公式，常用于生成邮件正文或 Chatter 帖子内容。
Choice (选项): 用于在屏幕组件（如单选按钮或下拉列表）中向用户呈现一组选项。

4. 扩展性：Apex 动作 (Apex Actions)

当声明式工具无法满足极其复杂的业务逻辑时（例如，调用外部系统的 API，或者执行复杂的计算），Flow 可以调用由开发人员编写的 Apex Action（Apex 动作）。这使得 Flow Builder 成为一个高度可扩展的平台，管理员和开发人员可以紧密协作。我们将在下面的示例中详细探讨这一点。

示例代码：通过 Invocable Apex 扩展 Flow

作为顾问，我们经常遇到的一个场景是客户需要执行一些 Flow 本身不支持的批量数据处理逻辑。这时，我们会与开发团队合作，创建一个可由 Flow 调用的 Invocable Apex Method（可调用 Apex 方法）。

假设客户希望在一个 Screen Flow 中，让用户输入一串客户姓氏，然后 Flow 需要将这些姓氏统一添加一个前缀（例如，公司代码）并返回结果。虽然这个特定例子可以用 Flow 公式实现，但它很好地展示了如何传递一个列表数据给 Apex 并接收一个列表作为返回值的基本模式。

以下是一个严格遵循 Salesforce 官方文档的 Apex 类，它包含一个可从 Flow 中调用的方法。

public class AccountNames {

    // 使用 @InvocableMethod 注解，使这个方法可以在 Flow、Process Builder 等自动化工具中被调用。
    // label 属性定义了它在 Flow Builder 中显示的名称。
    // description 提供了详细的说明，这对于维护至关重要。
    @InvocableMethod(label='Add Prefix to Account Names' description='Adds a prefix to a list of account names.' category='Account')
    public static List<String> addPrefix(List<String> names) {

        // 从输入的参数列表中获取第一个（也是唯一一个）字符串。
        // 在 Flow 中，这通常是一个文本变量。
        String prefix = names[0];
        
        // 创建一个新的列表来存储处理后的结果。
        List<String> prefixedNames = new List<String>();

        // 遍历输入的名称列表。
        // 注意：在实际的可调用方法中，我们通常会接收一个包装类（wrapper class）的列表，
        // 以便更灵活地处理多个输入参数。这个例子为了简单起见，直接使用了字符串列表。
        for (Integer i = 1; i < names.size(); i++) {
            String name = names[i];
            String prefixedName = prefix + '-' + name;
            prefixedNames.add(prefixedName);
        }
        
        // 返回处理后的字符串列表。
        // 这个返回值可以在 Flow 中被捕获并用于后续步骤。
        return prefixedNames;
    }
}

如何在 Flow 中使用这个 Apex 动作：

开发人员编写并部署上述 Apex 类。
在 Flow Builder 的画布上，添加一个 Action（动作）元素。
在“Category”（类别）中选择“Account”（我们在代码中定义的 `category`）。
选择名为“Add Prefix to Account Names”的动作（我们在代码中定义的 `label`）。
在“Set Input Values”（设置输入值）部分，将一个包含前缀和名称列表的 Flow 变量映射到 `names` 输入参数。
在“Store Output Values”（存储输出值）部分，将 Apex 方法的返回值（一个字符串列表）存储到一个新的 Flow 集合变量中，以便在后续屏幕或逻辑中使用。

注意事项

在设计和实施 Flow 解决方案时，我们必须向客户强调以下关键点，以确保系统的健壮性和可扩展性。

权限与运行上下文 (Permissions and Running Context)

一个 Flow 的运行上下文决定了它拥有何种数据访问权限。

User Context (用户上下文): Flow 遵循运行它的用户的权限、字段级安全性和共享规则。如果用户无权访问某个字段或记录，Flow 也会失败。
System Context (系统上下文): Flow 拥有访问和修改组织中所有数据的权限，会忽略用户的权限设置。

为客户选择正确的上下文至关重要。通常，对于后台记录处理，我们会推荐“System Context with Sharing”，它在拥有访问所有对象和字段权限的同时，仍然遵循共享规则。对于需要严格遵守用户权限的 Screen Flow，则必须在 User Context 中运行。

API 限制 (Governor Limits)

即使是声明式工具，Flow 在运行时也受 Salesforce 的 Governor Limits（管控限制）约束。这意味着在一个事务（transaction）中，SOQL 查询（`Get Records`）的数量、DML 操作（`Create`, `Update`, `Delete`）的数量都是有限的。

最严重的错误是在 Loop（循环）元素内部放置数据操作元素（如 `Get Records` 或 `Update Records`）。这会导致每循环一次就消耗一次 DML 或 SOQL 限额，当处理大量记录时，会迅速超出限制导致流程失败。

正确的方法（Bulkification）:

在循环开始前，使用一个 `Get Records` 获取所有需要处理的记录。
在循环内部，只使用 `Assignment` 元素来修改一个记录集合变量 (record collection variable) 中的值。
在循环结束后，使用一个 `Update Records` 元素，一次性更新整个记录集合变量。

这个模式确保了无论处理1条还是200条记录，都只消耗一次 SOQL 和一次 DML 操作。

错误处理 (Error Handling)

专业的解决方案必须考虑到可能出现的错误。Flow Builder 提供了 Fault Paths（故障路径）。我们可以从任何支持的数据或动作元素上拖出一条故障路径。如果该元素在运行时失败（例如，因为验证规则或数据库错误），流程会立即转到这条路径执行。我们通常建议客户在故障路径中执行以下操作：

向系统管理员发送一封包含错误详细信息（`$Flow.FaultMessage`）的电子邮件。
在自定义的“错误日志”对象中创建一个记录，方便跟踪和调试。
如果是在 Screen Flow 中，向用户显示一个友好的错误消息屏幕。

总结与最佳实践

作为 Salesforce 咨询顾问，我们视 Flow Builder 为交付业务价值最强大的工具之一。它实现了快速原型设计、敏捷开发和业务流程的持续优化。为了确保客户能够长期成功地使用和维护他们构建的自动化，我们总是强调以下最佳实践：

一个对象，一个自动化工具：我们强烈建议客户为每个对象的每种自动化类型（创建/更新前、创建/更新后、删除）只使用一个 Record-Triggered Flow。这样可以更容易地控制执行顺序，避免不同自动化工具之间的冲突。Flow Trigger Explorer 是管理这一点的绝佳工具。
清晰的命名规范：为所有资源（变量、常量等）和元素建立一套清晰的命名规范。例如，`varT_AccountName` 代表文本变量，`collR_ContactsToUpdate` 代表要更新的联系人记录集合。
添加描述：为 Flow 本身以及每个复杂的元素填写详细的描述。几个月后，当您或其他人需要修改这个 Flow 时，这些描述将是无价之宝。
模块化设计：对于复杂的逻辑，或者需要在多个 Flow 中重复使用的逻辑，应将其构建为可复用的 Subflow（子流程）。这使得主流程更简洁，也更易于维护。
永远不要硬编码 ID：不要在 Flow 中直接写入记录 ID、用户名或任何环境特定的值。应使用 `Get Records` 动态查询这些值，或使用自定义元数据类型、自定义设置来存储它们，以确保 Flow 在不同环境（如沙盒和生产）之间可以平滑迁移。

总之，Flow Builder 不再仅仅是一个“管理员工具”。它是一个强大的自动化平台，是连接业务需求与技术实现的桥梁。通过深入理解其原理、掌握最佳实践并明智地结合 Apex 进行扩展，我们可以为客户构建出真正能够推动业务增长的、可扩展且易于维护的解决方案。

精通 Salesforce Email Studio：咨询顾问指南之 AMPscript 与数据扩展实现动态个性化邮件

十月 07, 2025

阅读全文

Salesforce中文网