精通 Salesforce 审批流程：来自咨询顾问的自动化与最佳实践指南
背景与应用场景
作为一名 Salesforce 咨询顾问，我经常遇到的一个核心业务挑战是如何将企业内部复杂、繁琐且依赖人工的审批流程，转化为一个标准化、自动化、可追踪的系统化过程。无论是销售折扣的申请、市场费用的报销，还是人力资源的请假，这些流程往往涉及多个部门、多个层级的审批者，传统的邮件和口头沟通方式不仅效率低下，而且缺乏透明度，难以审计。这正是 Salesforce Approval Process (审批流程) 发挥巨大价值的地方。
Approval Process 是 Salesforce 平台提供的一个强大的声明式自动化工具，它允许我们根据预设的条件和规则，自动将记录（Record）提交给一个或多个用户进行批准或拒绝。它的核心目标是规范业务决策过程，确保关键操作符合公司政策，并为整个过程留下清晰的数字足迹。
让我们来看几个典型的应用场景：
销售折扣审批
一家公司的销售代表为赢得一个重要订单，需要提供超过 15% 的折扣。公司政策规定，超过 15% 的折扣必须由销售经理批准；如果超过 25%，则需要销售总监的最终批准。通过 Approval Process，当销售代表在Opportunity (商机) 记录上将折扣字段更新为 18% 并点击“提交审批”时，系统会自动将该商机锁定，并向其直属经理发送审批请求。经理批准后，如果折扣大于 25%，流程会自动升级至总监。整个过程无需任何邮件往来，所有沟通和决策都在 Salesforce 中完成。
费用报销审批
员工提交Expense Report (费用报销单) 对象的一条新记录。如果金额小于 500 元，其直属经理可以直接批准。如果金额在 500 到 2000 元之间，需要部门负责人批准。如果金额超过 2000 元，则需要财务部门介入审批。Approval Process 可以轻松实现这种基于金额的多层级、动态审批路径。
人力资源请假
员工通过自定义的Leave Request (请假申请) 对象提交申请。系统会根据请假天数和类型，自动路由给相应的审批人。例如，3 天以内的病假由直属经理审批即可，而超过 10 天的年假则可能需要经理和 HRBP 共同批准。
通过这些场景，我们可以看到 Approval Process 不仅仅是一个技术工具，它更是企业实现流程治理、风险控制和运营增效的关键业务实践。作为顾问，我的职责就是帮助客户梳理这些现实世界的业务流程，并将其精准地映射到 Salesforce 的自动化能力之上。
原理说明
要成功设计并实施一个高效的 Approval Process，我们必须深入理解其核心构成组件和工作原理。一个完整的审批流程可以被分解为以下几个关键部分：
1. Process Definition (流程定义)
这是审批流程的起点，定义了该流程适用于哪个 Object (对象)，例如 Opportunity、Account 或自定义对象。
2. Entry Criteria (入口条件)
定义了什么样的记录有资格进入此审批流程。这是一个逻辑条件，例如 Opportunity.Discount_Percentage__c > 0.15 AND Opportunity.StageName = 'Negotiation'。只有满足这些条件的记录，用户才能看到“Submit for Approval”按钮并成功提交。
3. Initial Submission Actions (初始提交操作)
当用户点击“Submit for Approval”并且记录满足入口条件后，系统会立即执行一系列预设操作。最重要、最常见的操作是 Record Locking (记录锁定)。一旦记录被锁定，除了当前指定的审批人和管理员外，任何人都无法编辑该记录，这确保了审批数据的一致性和完整性。其他操作还包括：更新字段（例如将“审批状态”字段更新为“审批中”）、发送邮件提醒、创建任务或发送 Outbound Message (出站消息)。
4. Approval Steps (审批步骤)
这是流程的核心，定义了“谁”来审批以及在“什么条件”下审批。一个审批流程可以包含一个或多个步骤。每个步骤都包含：
- Step Criteria (步骤条件): 决定记录是否需要进入此步骤。可以选择让所有记录都进入此步骤，或者设置特定条件，例如
Amount > 100000。 - Assign to Approver (分配审批人): 指定该步骤的审批人。Salesforce 提供了非常灵活的分配方式：
- Let the submitter choose the approver manually: 提交者手动选择。
- Automatically assign to a user or queue: 自动分配给某个特定用户或 Queue (队列)。对于团队审批场景，使用队列是最佳实践。
- Automatically assign using a standard or custom hierarchy field: 自动分配给提交者经理（基于 User 对象上的 Manager 字段）或其他层级关系中的用户。
- Actions for 'If this step is approved...': 当审批人批准此步骤后，系统可以执行的操作，以及决定流程是进入下一步，还是直接最终批准。
- Actions for 'If this step is rejected...': 当审批人拒绝此步骤后，系统可以执行的操作，以及决定流程是退回上一步，还是直接最终拒绝。
5. Final Approval / Rejection / Recall Actions (最终批准/拒绝/撤回操作)
当整个审批流程走完（所有步骤都批准）或在任何一步被最终拒绝时，系统会执行相应的最终操作。这通常包括：
- Final Approval Actions: 更新字段（如将状态改为“已批准”）、发送最终批准通知、解锁记录。
- Final Rejection Actions: 更新字段（如将状态改为“已拒绝”）、发送拒绝通知、解锁记录。
- Recall Actions: 当提交者在流程结束前撤回审批请求时执行的操作。
通过组合这些组件，我们可以构建出从简单到极其复杂的业务审批逻辑，将现实世界的决策流程忠实地反映在系统中。
示例代码
虽然 Approval Process 主要是通过点击配置完成的，但在某些高级场景下，我们需要通过 Apex 代码来与它进行交互，最常见的场景就是通过代码自动提交记录进行审批。例如，当一个外部系统通过 API 创建了一条记录，并希望自动触发审批流程时，我们就需要用到 Apex。
Salesforce 提供了 Approval 命名空间下的类来处理这类请求。以下示例代码来自 Salesforce 官方文档，展示了如何使用 Apex 提交一个特定的 Opportunity 记录进入审批流程。
// 假设我们有一个 Opportunity 记录需要提交审批
// 我们已经获取了它的 ID，例如：'006D000000AD4eN'
Id oppId = '006D000000AD4eN';
Opportunity opp = [SELECT Id, Name, Amount FROM Opportunity WHERE Id = :oppId];
// 1. 创建一个 ProcessSubmitRequest 对象来准备提交请求
Approval.ProcessSubmitRequest req = new Approval.ProcessSubmitRequest();
// 2. 设置提交请求的上下文信息
// 设置提交请求的备注信息
req.setComments('Submitting for approval automatically via Apex.');
// 设置需要提交审批的记录 ID
req.setObjectId(opp.Id);
try {
// 3. 调用 Approval.process 方法并传入请求对象
// 这个方法会尝试将记录提交到与其匹配的活动审批流程中
Approval.ProcessResult result = Approval.process(req);
// 4. 检查提交结果是否成功
if (result.isSuccess()) {
System.debug('Record submitted for approval successfully. Process Instance ID: ' + result.getInstanceIds()[0]);
// 可以在这里执行成功后的逻辑，例如更新相关记录的状态
} else {
// 5. 如果提交失败，则处理错误
// 遍历错误信息并输出
for(Approval.ProcessResult.Error error : result.getErrors()) {
System.debug('Error submitting for approval: ' + error.getStatusCode() + ' - ' + error.getMessage());
}
}
} catch (System.DmlException e) {
// 6. 捕获可能发生的 DML 异常或其他系统异常
// 例如，如果记录不满足任何活动审批流程的入口条件，就会抛出异常
System.debug('An exception occurred during approval submission: ' + e.getMessage());
}
代码注释详解：
- 第 5-6 行: 首先，我们获取需要提交审批的记录。在真实场景中，这个 ID 可能来自 Trigger、一个 LWC 组件，或者一个批处理任务。
- 第 9 行: 实例化
Approval.ProcessSubmitRequest对象，这是提交审批的核心载体。 - 第 12-14 行: 使用
setComments()和setObjectId()方法设置请求的必要参数。setObjectId()是必须的，它告诉 Salesforce 要对哪条记录进行操作。 - 第 17 行:
Approval.process(req)是执行提交的关键方法。它返回一个Approval.ProcessResult对象，包含了操作的结果信息。 - 第 20 行: 通过
result.isSuccess()判断操作是否成功。如果成功，可以通过result.getInstanceIds()获取新创建的审批流程实例的 ID。 - 第 23-26 行: 如果提交失败，
result.getErrors()会返回一个错误列表，我们可以遍历它来获取详细的错误码和错误信息，这对于调试至关重要。 - 第 28-32 行: 使用
try-catch块来捕获异常是一个非常重要的最佳实践。例如，如果没有任何活动的审批流程与该记录的入口条件匹配，Approval.process()方法会抛出一个异常，而不是在ProcessResult中返回一个错误。
注意事项
在设计和实施 Approval Process 时，必须考虑以下几点，以确保流程的健壮性和可维护性：
1. 权限 (Permissions)
确保提交者拥有“读取”他们要提交的记录的权限，并且其 Profile 或 Permission Set 允许他们提交审批。同样，审批人也必须对该对象拥有至少“读取”权限，否则他们无法查看记录详情并做出决策。
2. 记录锁定 (Record Locking)
记录锁定是 Approval Process 的一个强大功能，但也是一个常见的混淆点。一旦记录被锁定，用户（非管理员）将无法编辑。如果你的业务流程要求审批人在批准前修改记录（例如，经理需要调整折扣率再批准），你必须在审批流程的设置中明确勾选“Administrators OR the currently assigned approver can edit records during approval.”。
3. 无法触发的自动化 (Automation That Doesn't Fire)
由 Approval Process 中的 Field Update (字段更新) 触发的数据库变更，不会再次触发该对象上的 Workflow Rules, Process Builder, 或大部分 Flow。这是一个重要的执行顺序问题。如果你依赖于审批后的字段更新来触发其他自动化，你需要重新评估你的设计，可能需要将后续逻辑移到 Flow 或 Apex Trigger 中，并确保它们能在审批操作的上下文中被正确调用。
4. API 与治理限制 (API and Governor Limits)
每个 Salesforce Org 对每个对象的活动审批流程数量有限制（通常是 300 个）。虽然这个限制很高，但在大型企业或复杂的 Org 中也需要注意。此外，通过 Apex 批量提交审批时，要注意 Apex 的事务限制，如 DML 语句和 SOQL 查询的限制。
5. 审批人变更处理 (Handling Approver Changes)
如果审批人被硬编码为某个具体用户，当该用户离职或转岗时，审批流程就会中断。最佳实践是使用 Queue (队列) 或基于层级关系（如 Manager 字段）的动态审批人分配。这样，当人员变动时，你只需要更新队列成员或用户的 Manager 字段，而无需修改审批流程本身。
总结与最佳实践
Salesforce Approval Process 是一个功能强大且灵活的工具，能够将复杂的业务审批流程数字化和自动化，从而显著提高企业运营效率、合规性和透明度。作为一名咨询顾问，我始终向客户强调，成功的实施不仅仅是技术配置，更是对业务流程的深刻理解和优化。
以下是一些关键的最佳实践总结：
- 先规划，后构建: 在进入 Salesforce 设置界面之前，使用流程图（如 Visio 或 Lucidchart）完整地绘制出业务审批的每一个步骤、条件和参与者。这有助于与业务方达成共识，并发现潜在的逻辑漏洞。
- 保持简单: 避免创建过于冗长和复杂的审批流程。如果一个流程有超过 10 个步骤，或者逻辑分支非常复杂，请考虑是否可以将其拆分为多个独立的流程，或者使用 Flow 来实现更复杂的逻辑。
- 善用队列和动态分配: 尽可能避免将审批人硬编码为特定用户。优先使用 Queues, Manager Fields, 或自定义的 User 查找字段来动态分配审批任务，这会大大降低未来的维护成本。
- 清晰的沟通: 在邮件模板和审批页面布局中提供清晰、简洁的指示。审批人应该能够轻松地理解他们需要审批什么内容，以及批准或拒绝的后果是什么。
- 充分测试: 在 Sandbox 环境中，使用不同角色的测试用户，对所有可能的路径进行详尽的测试，包括批准、拒绝、多步骤、单步骤、撤回以及边界条件（例如，刚好满足或不满足入口条件的记录）。
- 拥抱代码作为补充: 对于标准 UI 无法满足的场景，如自动提交、复杂的审批人动态查找或与外部系统集成，要善于利用 Apex 与 Approval Process 进行结合，以实现端到端的自动化。
通过遵循这些原则，你可以构建出不仅满足当前需求，而且易于维护和扩展的健壮审批解决方案，为企业创造持久的业务价值。
评论
发表评论