System validation versus custom validation in the save order
Key Takeaway
After a workflow field update, Salesforce reruns system validation but not custom validation rules, so a value the update writes can break a validation rule and still be saved.
When a record is saved, Salesforce runs a fixed sequence of steps called the save order. Validation happens at more than one point in that sequence. System validation is Salesforce's own checking of things like required values, field formats, and field length. Custom validation rules are the rules an admin builds. If you know where each one runs, and which later steps rerun only one of them, you can predict whether a value set by automation gets checked.
Where validation runs in the save order
The browser does very little checking. Before the save reaches the server, the browser runs JavaScript validation only for dependent picklist fields, limiting each one to its available values. Every other check, including all validation rules, runs on the server.
On the server, Salesforce runs these steps in order:
- Load the original record, then load the new field values over the old ones.
- Run the first round of system validation.
- Run before-save record-triggered flows.
- Run all before triggers.
- Run the second validation round.
- Run duplicate rules.
- Save the record to the database, but don't commit it yet.
- Run after triggers and the rest of the automation.
Every record change goes through this save order, whatever tool makes it. Flows, Apex, and user edits are all subject to the object's validation rules.
A duplicate rule that uses the block action stops the save. The record isn't saved. Later steps, such as after triggers and workflow rules, don't run.