Business Logic and Process Automation · Topic 3 of 7
Validation Rules
Salesforce validation rules: error condition formulas, error messages and locations, ISCHANGED, PRIORVALUE, ISNEW, REGEX, and when rules run on save.
- 4 min
- The formula describes invalid data; true blocks the save.
- Error messages can appear at the top of the page or next to a field.
- ISCHANGED, PRIORVALUE and ISNEW handle change-based rules.
What it is
A validation rule checks data when a record is saved. It contains an error condition formula: if the formula is true, the save is blocked and the user sees an error message. If it is false, the record saves.
Validation rules are the declarative way to enforce data quality, such as "a closed opportunity must have a reason" or "discount cannot exceed 30%".
How it works
Parts of a validation rule
| Part | What you set |
|---|---|
| Rule name and description | What the rule checks |
| Error condition formula | Returns true when the data is invalid |
| Error message | The text the user sees |
| Error location | Top of the page, or next to a specific field |
| Active | Only active rules run |
The key habit is to write the formula for the bad case. "Amount must be positive" becomes Amount <= 0.
Useful functions
| Function | Use |
|---|---|
| ISBLANK | Require a value, for example a reason when the stage is Closed Lost |
| ISPICKVAL | Check a picklist value |
| ISCHANGED | Check whether a field changed in this save |
| PRIORVALUE | Compare with the value before this save |
| ISNEW | Apply a check only when the record is created |
| REGEX | Match a pattern, such as a postcode format |
| VLOOKUP | Check a value against records in a custom object |
| $User, $Profile, $Permission | Exempt certain users, profiles or custom permissions |
A typical rule: the stage cannot move back from Closed Won.
ISCHANGED(StageName) && ISPICKVAL(PRIORVALUE(StageName), "Closed Won")
When validation rules run
- On every save from the user interface, the API, imports, Data Loader and automation that updates the record.
- Before the record is committed, after system validation such as required fields.
- Record-triggered flows that run before save run before validation rules, so the rule checks their result.
Because rules apply to every source, an integration or a large data load can fail if it does not meet them. A common approach is to exempt an integration user with a custom permission checked in the formula.
Validation rules versus other tools
| Need | Tool |
|---|---|
| A field must always have a value | Required field setting, or a validation rule when it depends on other values |
| Data must follow a rule based on other fields | Validation rule |
| Fix data automatically instead of blocking | Before-save record-triggered flow |
| Restrict which picklist values can be chosen | Dependent picklists or record types |
A worked example: a company requires a Loss Reason whenever an opportunity is set to Closed Lost, and the integration user must be exempt. The builder writes ISPICKVAL(StageName, "Closed Lost") && ISBLANK(Loss_Reason__c) && NOT($Permission.Bypass_Validation), sets the error to appear next to the Loss Reason field, and assigns the custom permission to the integration user through a permission set.
Read the requirement as "block the save when...". Whatever follows "when" is your formula.
How the exam asks about this
- "Prevent users from changing a field after the record is approved." ISCHANGED with a status check.
- "Allow administrators to bypass the rule." A $Profile or $Permission check in the formula.
- "Ensure a field follows a pattern." REGEX.
What to remember for the exam
- The formula describes invalid data; true blocks the save.
- Error messages can appear at the top of the page or next to a field.
- ISCHANGED, PRIORVALUE and ISNEW handle change-based rules.
- Rules apply to all saves, including imports and the API.
- Exempt users with $Profile, $User or a custom permission.
A new validation rule also applies to existing records the next time they are edited, which can block unrelated updates and data loads.
Common mistakes
Writing the formula for the valid case. The formula must be true when data is wrong.
Forgetting integrations and imports. They are blocked too unless exempted.
Using a validation rule to correct data. Validation rules only block; use a flow to change values.
Check yourself
What happens when a validation rule's formula returns true?
The save is blocked and the error message is shown.
Which function compares a field with its value before the current save?
PRIORVALUE.
How can an integration user be exempted from a validation rule?
Check a custom permission, profile or user in the formula and grant it to that user.
Topic 3 of 7 in Business Logic and Process Automation
Test yourself on Business Logic and Process Automation
The full Salesforce Platform App Builder question bank has 648 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Salesforce. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.