SFDC记录保存顺序完整版本（Spring25版本)

news/2025/3/3 13:44:57/文章来源:https://www.cnblogs.com/paynev/p/18748042

SFDC记录保存顺序完整版本（Spring'25版本)

前言

Salesforce在记录保存过程有一套执行顺序，并且Apex是不可以打断点的，所以掌握这个顺序对我们排查问题定位问题所在位置很有帮助，也是每个开发人员都应该掌握的知识。

正文

When you save a record with an insert, update, or upsert statement, Salesforce performs a sequence of events in a certain order. 当您使用 insert 、 update 或 upsert 语句保存记录时，Salesforce会按特定顺序执行一系列事件。

Before Salesforce executes these events on the server, the browser runs JavaScript validation if the record contains any dependent picklist fields. The validation limits each dependent picklist field to its available values. No other validation occurs on the client side. 在Salesforce在服务器上执行这些事件之前，如果记录包含任何依赖的选择列表字段，浏览器将运行JavaScript验证。验证将每个依赖选择列表字段限制为其可用值。在客户端不会发生其他验证。

On the server, Salesforce performs events in this sequence. 在服务器上，Salesforce按此顺序执行事件。

Loads the original record from the database or initializes the record for an upsert statement. 从数据库中加载原始记录，或将该记录保存为 upsert 语句。
Loads the new record field values from the request and overwrites the old values. 从请求中加载新的记录字段值并覆盖旧的价值观

Salesforce performs different validation checks depending on the type of request. Salesforce根据请求类型执行不同的验证检查。
- For requests from a standard UI edit page, Salesforce runs these system validation checks on the record: 对于来自标准UI编辑页面的请求，Salesforce运行这些系统对记录进行验证检查：
  - Compliance with layout-specific rules 遵守特定布局规则
  - Required values at the layout level and field-definition level 布局级别和字段定义级别的必需值
  - Valid field formats 有效字段格式
  - Maximum field length 最大字段长度
  Additionally, if the request is from a User object on a standard UI edit page, Salesforce runs custom validation rules. 此外，如果请求来自标准UI编辑页面上的User对象，Salesforce将运行自定义验证规则。
- For requests from multiline item creation such as quote line items and opportunity line items, Salesforce runs custom validation rules. 对于来自多行项目创建（如报价行项目和商机行项目）的请求，Salesforce会运行自定义验证规则。
- For requests from other sources such as an Apex application or a SOAP API call, Salesforce validates only the foreign keys and restricted picklists. Before executing a trigger, Salesforce verifies that any custom foreign keys don’t refer to the object itself. 对于来自Apex应用程序或SOAP API调用等其他来源的请求，Salesforce仅验证外键和受限选择列表。在执行触发器之前，Salesforce会验证任何自定义外键都没有引用对象本身。
Executes record-triggered flows that are configured to run before the record is saved. 执行配置为在保存记录之前运行的记录触发流。
Executes all before triggers. 执行所有 before 触发器。
Runs most system validation steps again, such as verifying that all required fields have a non-null value, and runs any custom validation rules. The only system validation that Salesforce doesn't run a second time (when the request comes from a standard UI edit page) is the enforcement of layout-specific rules. 再次执行最简单的系统验证步骤，例如验证所有必填字段是否具有非 null 值，并运行任何自定义验证规则。Salesforce不会再次运行的唯一系统验证（当请求来自标准UI编辑页面时）是执行特定于布局的规则。
Executes duplicate rules. If the duplicate rule identifies the record as a duplicate and uses the block action, the record isn’t saved and no further steps, such as after triggers and workflow rules, are taken. 执行重复的规则。如果重复规则将记录标识为重复并使用阻止操作，则不会保存记录，也不会执行其他步骤，如 after 触发器和工作流规则。
Saves the record to the database, but doesn't commit yet. 将记录复制到数据库，但尚未提交。
Executes all after triggers. 执行所有 after 触发器。
Executes assignment rules. 执行分配规则。
Executes auto-response rules. 执行自动响应规则。
Executes workflow rules. If there are workflow field updates: 执行工作流规则。如果有工作流字段更新：
1. Updates the record again. 再次刷新记录。
2. Runs system validations again. Custom validation rules, flows, duplicate rules, processes built with Process Builder, and escalation rules aren’t run again. 再次验证系统。自定义验证规则、流、重复规则、使用Process Builder构建的流程以及升级规则不会再次运行。
3. Executes before update triggers and after update triggers, regardless of the record operation (insert or update), one more time (and only one more time) 执行 before update 触发器和 after update 触发器，无论记录操作（插入或更新），一次以上（仅一次以上）
Executes escalation rules. 执行升级规则。
Executes these Salesforce Flow automations, but not in a guaranteed order. 执行这些Salesforce Flow自动化，但不按保证的顺序执行。
- Processes built with Process Builder 使用Process Builder构建的流程
- Flows launched by workflow rules (flow trigger workflow actions pilot) 由工作流规则启动的流（流触发工作流操作试点）
- Note：To control the order of execution of Salesforce Flow automations, use record-triggered flows. See Manage Record-Triggered Flows 注意：要控制Salesforce Flow自动化的执行顺序，请使用记录触发流。请参阅管理记录触发流

When a process or flow executes a DML operation, the affected record goes through the save procedure. 当进程或流执行DML操作时，受影响的记录将经历保存过程。
Executes record-triggered flows that are configured to run after the record is saved 执行记录触发的流，这些流配置为在保存记录后运行
Executes entitlement rules. 执行权利规则。
If the record contains a roll-up summary field or is part of a cross-object workflow, performs calculations and updates the roll-up summary field in the parent record. Parent record goes through save procedure. 如果记录包含汇总汇总字段或属于跨对象工作流的一部分，则执行计算并更新父记录中的汇总汇总字段。父记录通过保存过程。
If the parent record is updated, and a grandparent record contains a roll-up summary field or is part of a cross-object workflow, performs calculations and updates the roll-up summary field in the grandparent record. Grandparent record goes through save procedure. 如果父记录已更新，并且祖父记录包含汇总汇总字段或属于跨对象工作流的一部分，则会执行计算并更新祖父记录中的汇总汇总字段。祖父母记录通过保存程序。
Executes Criteria Based Sharing evaluation. 执行基于标准的共享评估。
Commits all DML operations to the database. 将所有DML操作提交到数据库。
After the changes are committed to the database, executes post-commit logic. Examples of post-commit logic (in no particular order) include: 将更改提交到数据库后，执行提交后逻辑。提交后逻辑的示例（没有特定顺序）包括：
- Sending email 发送电子邮件
- Enqueued asynchronous Apex jobs, including queueable jobs and future methods 已排队的异步Apex作业，包括可替换作业和将来的方法
- Asynchronous paths in record-triggered flows 记录触发流中的异步路径
- Note: During a recursive save, Salesforce skips steps 9 (assignment rules) through 17 (roll-up summary field in the grandparent record). 注意：在递归保存期间，Salesforce跳过步骤9（分配规则）到17（祖父记录中的汇总字段）。

额外考虑

Note these considerations when working with triggers. 使用触发器时请注意这些注意事项。

If a workflow rule field update is triggered by a record update, Trigger.old doesn’t hold the newly updated field by the workflow after the update. Instead, Trigger.old holds the object before the initial record update was made. For example, an existing record has a number field with an initial value of 1. A user updates this field to 10, and a workflow rule field update fires and increments it to 11. In the update trigger that fires after the workflow field update, the field value of the object obtained from Trigger.old is the original value of 1, and not 10. See Trigger.old values before and after update triggers. 如果工作流规则字段更新是由记录更新触发的，则 Trigger.old 不会在更新后保存工作流新更新的字段。相反， Trigger.old 在初始记录更新之前保存对象。例如，现有记录具有初始值为1的数字字段。用户将此字段更新为10，工作流规则字段更新将触发并将其递增为11。在 update 触发器，该触发器在工作流字段更新后触发，从 Trigger.old 获得的对象是原始值1，而不是10。更新触发器之前和之后的旧值。
If a DML call is made with partial success allowed, triggers are fired during the first attempt and are fired again during subsequent attempts. Because these trigger invocations are part of the same transaction, static class variables that are accessed by the trigger aren't reset. See Bulk DML Exception Handling. 如果在允许部分成功的情况下进行DML调用，则在第一次尝试期间触发器，并在后续尝试期间再次触发。由于这些触发器调用是同一事务的一部分，因此触发器访问的静态类变量不会重置。请参见批量DML异常处理。
If more than one trigger is defined on an object for the same event, the order of trigger execution isn't guaranteed. For example, if you have two before insert triggers for Case and a new Case record is inserted. The firing order of these two triggers isn’t guaranteed. 如果为同一事件在一个对象上定义了多个触发器，则不能保证触发器的执行顺序。例如，如果Case有两个 before insert 触发器，并且插入了一个新的Case记录。这两个触发器的发射顺序无法保证。
To learn about the order of execution when you insert a non-private contact in your org that associates a contact to multiple accounts, see AccountContactRelation. 若要了解在组织中插入将联系人与多个帐户关联的非私人联系人时的执行顺序，请参阅AccountContactRelation。
To learn about the order of execution when you’re using before triggers to set Stage and Forecast Category, see Opportunity. 要了解使用 before 触发器设置阶段和预测类别，请参阅机会。
In API version 53.0 and earlier, after-save record-triggered flows run after entitlements are executed. 在API版本53.0及更早版本中，保存后记录触发流在执行授权后运行。