Triggers — Order of Execution

同学们，我们现在来聊聊在Salesforce里保存一条记录时，后台到底发生了哪些事情。这就像一条精心设计的流水线，每一步都有它的道理。理解这个顺序，对你写好触发器和自动化特别关键。 我们想象一下，当你点下保存按钮，Salesforce并不是直接就把数据丢进数据库，而是先做一系列准备和检查。首先，系统会把数据加载好，接着在第2步，就会跑第一遍验证规则，比如检查必填项、字段格式对不对，确保数据基础没问题。 然后到了第4步，很关键，，“之前触发”，就在这里执行。这个Apex before trigger让你有机会在数据真正存入数据库之前，再修改、再润色一下字段值。改完之后，不能直接放行，第5步会立即再次运行验证，确保你做的修改也是合法合规的。 验证通过，这时候数据才真正写入数据库，但事务还没有提交，还留着反悔的余地。紧接着第8步，，“之后触发”，执行，也就是after trigger。因为记录已经落库，此时你可以拿到记录ID，也能查询到数据库里的最新状态，适合做一些关联更新或日志记录，但记住，不能再直接修改当前记录本身了。 走出触发器，就轮到工作流规则登场。在原本的执行顺序里，工作流大概是第11步。这里有一个很重要的行为：如果工作流规则里包含了，字段更新，，它会像一个回声一样，引发一次额外的保存循环。也就是说，整个保存序列，包括前面的验证、before trigger、after trigger，都会被重新触发一遍。Salesforce限制这个回圈只会额外跑一次，避免无限循环，这个问题你要小心设计，别让触发器和工作流互相踢皮球。 再往后，流程自动化（比如Flow和Process Builder）在第13步左右运行。但是请注意，这里没有一个固定的执行顺序，你不能依赖哪个流程先跑。如果你的业务里有严格的顺序要求，比如必须先算折扣再算总价，那么最好改用，记录触发的流程，，在里面设定清晰的排序逻辑，这样才可控。 还有一种特殊情形，叫循环保存。在那种由于字段更新引发的二次保存过程中，步骤