Salesforce 工作流规则：在 Flow 时代下为管理员准备的实用指南

背景与应用场景

大家好，我是一名 Salesforce 管理员 (Administrator)。在我的日常工作中，自动化是提升效率、确保数据一致性和执行业务流程的关键。今天，我想和大家深入探讨 Salesforce 的一个经典自动化工具：工作流规则 (Workflow Rules)。尽管 Salesforce 现在主推 Flow 作为其首选的自动化解决方案，但理解 Workflow Rules 依然至关重要，因为在许多现有的 Salesforce 组织中，它们仍在默默地发挥着重要作用。

Workflow Rules 是一种基于特定条件自动执行后续操作的业务逻辑引擎。当记录被创建或更新时，如果满足预设的条件，Workflow Rules 就会被触发，从而自动执行一些标准化的后台操作。这使得我们管理员无需编写任何代码，就能实现许多常见的自动化需求。

以下是一些典型的应用场景：

机会跟进提醒：当一个“机会 (Opportunity)”的“结束日期 (Close Date)”即将到来（例如，未来7天内），但其“阶段 (Stage)”仍处于早期阶段时，自动创建一个“任务 (Task)”分配给机会的所有者，提醒他及时跟进。

关键客户升级通知：

案例状态同步：

系统集成触发：

通过这些场景，我们可以看到 Workflow Rules 的核心价值在于：在正确的时间，对正确的记录，执行正确的操作。它帮助我们减少了大量的手动操作，降低了人为错误的风险，并确保了业务流程的标准化执行。

原理说明

要完全掌握 Workflow Rules，我们需要理解其三大核心组成部分：评估条件 (Evaluation Criteria)、规则条件 (Rule Criteria) 和 工作流操作 (Workflow Actions)。当一个事件（如记录创建或更新）发生时，Salesforce 会按照这个逻辑链进行判断和执行。

1. 对象 (Object)

首先，每一个 Workflow Rule 都必须依附于一个特定的 Salesforce 对象，例如客户 (Account)、联系人 (Contact) 或任何自定义对象。这个规则只会对该对象的记录进行监控和操作。

2. 评估条件 (Evaluation Criteria)

这是 Workflow Rule 的触发时机。它决定了 Salesforce 应该在什么时候去检查这条规则是否满足条件。我们有三个选项：

创建时 (created)：规则仅在记录首次被创建时进行评估。后续对该记录的任何编辑都不会触发此规则。

创建时和每次编辑时 (created, and every time it's edited)：

创建时，以及后续编辑以满足条件时 (created, and any time it's edited to subsequently meet criteria)：

3. 规则条件 (Rule Criteria)

这是规则的核心判断逻辑。当评估条件被满足后，Salesforce 会检查这里的规则条件，以确定是否要执行后续的操作。我们有两种方式来定义条件：

条件满足 (Criteria are met)：通过下拉菜单和逻辑运算符（AND, OR）来组合多个字段的条件判断。例如，`Case: Status equals Closed` AND `Case: Priority equals High`。这种方式直观且易于配置。

公式计算结果为真 (Formula evaluates to true)：

4. 工作流操作 (Workflow Actions)

当规则条件被满足时，系统就会执行预定义的操作。这些操作分为两种：立即操作 (Immediate Actions) 和 时间依赖型操作 (Time-Dependent Actions)。时间依赖型操作会在满足条件的某个时间点之后执行（例如，触发日期的7天后）。Workflow Rule 支持四种核心操作类型：

新建任务 (New Task)：自动创建一个任务记录，并可以将其分配给特定用户、角色或记录所有者。这对于确保关键活动得到跟进非常有用。

电子邮件提醒 (New Email Alert)：

字段更新 (New Field Update)：

出站消息 (New Outbound Message)：

示例代码

Workflow Rules 本身是声明式工具，不涉及 Apex 代码。然而，其“出站消息 (Outbound Message)” 操作与外部系统交互时，会生成一个特定格式的 SOAP XML 消息。作为管理员，理解这个消息的结构有助于我们与开发或集成团队沟通。以下是 Salesforce 官方文档中一个出站消息通知的示例结构，它展示了当工作流规则触发时，Salesforce 发送给外部侦听器 (listener) 的内容。

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <soapenv:Body>
  <notifications xmlns="http://soap.sforce.com/2005/09/outbound">
   <OrganizationId>00DD0000000K3yNMAS</OrganizationId>
   <ActionId>04kD00000000001AAA</ActionId>
   <SessionId>00DD0000000K3yN!AR8AQBM8E8pEL3_8a34qls2NZEqg_idd_4iNp_2nWUQAJ.9sgr1k2w0iG7JAxY3i3nKMMTEH22A4jCIIT00001</SessionId>
   <EnterpriseUrl>https://yourInstance.salesforce.com/services/Soap/c/56.0/00DD0000000K3yN</EnterpriseUrl>
   <PartnerUrl>https://yourInstance.salesforce.com/services/Soap/u/56.0/00DD0000000K3yN</PartnerUrl>
   <Notification>
    <Id>04lD00000000001AAA</Id>
    <sObject xsi:type="sf:Account" xmlns:sf="urn:sobject.enterprise.soap.sforce.com">
     <sf:Id>001D00000000001AAA</sf:Id>
     <sf:Name>Acme</sf:Name>
     <sf:Phone>(415)555-1212</sf:Phone>
     <sf:NumberOfEmployees>1000</sf:NumberOfEmployees>
    </sObject>
   </Notification>
  </notifications>
 </soapenv:Body>
</soapenv:Envelope>

注释说明

<OrganizationId>：触发此消息的 Salesforce 组织的唯一 ID。

<ActionId>

<SessionId>

<EnterpriseUrl>

<PartnerUrl>

<Notification>

<sObject>

<sf:Id>

<sf:Name>

这个 XML 结构是固定的，外部系统需要构建一个能够解析此格式的 SOAP Web Service 来接收和处理这些数据。

注意事项

作为管理员，在使用和维护 Workflow Rules 时，我们必须清楚它的局限性和潜在风险。

未来方向：Flow 是首选
最重要的一点：Salesforce 已经宣布将停用 (retire) Workflow Rules 和 Process Builder。虽然目前它们仍然可以正常工作，但所有新的自动化逻辑都应该使用 Flow Builder 来构建。Flow 提供了远超 Workflow Rules 的功能，例如可以删除记录、创建多个相关记录、与用户进行屏幕交互、执行复杂的逻辑分支等。我们应该制定计划，逐步将现有的 Workflow Rules 迁移到 Flow 中。
执行顺序 (Order of Execution)
Workflow Rules 在 Salesforce 复杂的保存执行顺序中处于一个比较靠前的位置。它们在 `before save` 和 `after save` 触发器之后，但在大多数其他自动化（如 Process Builder, Flow, Escalation Rules）之前执行。特别需要注意的是，如果一个 Workflow Rule 的字段更新操作导致记录再次被保存，它会重新触发整个保存流程（包括 Validation Rules 和 Triggers），这可能会导致递归循环或非预期的行为。因此，在调试问题时，理解执行顺序至关重要。
功能限制
与现代的 Flow 相比，Workflow Rules 的功能非常有限：
- 它无法创建除任务以外的任何其他记录。
- 它无法删除记录。
- 它只能更新触发记录本身或其父记录（对于主从关系）。无法更新不相关的记录或子记录。
- 它不支持复杂的逻辑分支或循环。
- 它无法调用 Apex 代码或与用户进行交互。
时间依赖型操作的管理
所有待处理的时间依赖型操作都可以在“设置 (Setup)”菜单下的“时间依赖型工作流 (Time-Based Workflow)”队列中查看和管理。如果某个记录在待处理操作执行前被修改，并且不再满足 Workflow Rule 的条件，那么这个待处理操作会自动从队列中移除。这是 Salesforce 的一个内置安全机制，但有时也可能让管理员感到困惑，需要到队列中去确认操作的状态。
调试与排错
当 Workflow Rule 没有按预期工作时，调试日志 (Debug Logs) 是我们最好的朋友。通过设置用户跟踪标记并查看日志，我们可以清晰地看到 `WF_CRITERIA_BEGIN`, `WF_CRITERIA_END`, `WF_ACTION` 等事件，从而判断是条件不满足还是操作执行失败。

总结与最佳实践

Workflow Rules 作为 Salesforce 的元老级自动化工具，为无数管理员提供了便捷、可靠的自动化能力。它简单、直观，对于处理一些基础的自动化场景（如发送邮件、更新字段）仍然非常高效。

然而，技术在不断演进。在 Flow 已经成为 Salesforce 平台自动化核心的今天，我们作为管理员也需要与时俱进。以下是关于 Workflow Rules 的最终总结和最佳实践建议：

新自动化，用 Flow：对于任何新的自动化需求，请毫不犹豫地选择 Flow。它更强大、更灵活，并且是 Salesforce 未来发展的方向。现在投入时间学习 Flow 将会带来长期的回报。
谨慎维护现有规则：对于组织中已经存在的、运行良好的 Workflow Rules，如果没有紧急的修改需求，可以暂时保留。但是，当需要对某个旧规则进行较大规模的修改或扩展时，应该优先考虑将其重构为一个新的 Flow。这不仅能利用 Flow 的强大功能，也有助于逐步减少技术债务。
制定迁移计划：主动规划，将关键或复杂的 Workflow Rules 迁移到 Flow。可以从业务影响力最大、维护成本最高的规则开始。迁移不仅是功能的平移，更是一个重新审视和优化业务流程的好机会。
文档和命名规范：无论是维护旧的 Workflow Rules 还是创建新的 Flow，清晰的命名和详尽的描述都至关重要。在描述中写清楚这个自动化的业务目的、触发条件和执行的操作，这样能让未来的你或其他管理员快速理解其作用。
优先考虑声明式工具：在考虑使用 Apex 代码之前，始终先评估是否能用 Flow 解决问题。Salesforce 的“点击而非代码 (clicks-not-code)”理念鼓励我们最大限度地利用平台内置的声明式工具，这能降低开发和维护成本。

总而言之，Workflow Rules 是我们工具箱中一个值得尊敬的“老兵”。通过理解它的原理、优势和局限，我们可以更好地维护现有系统，并更平稳、更自信地迈向以 Flow 为中心的自动化新时代。

Salesforce中文网