Salesforce validation rules check the data in a record every time it is saved. Each rule has a formula that returns true or false: if the formula returns true, the data is invalid, Salesforce blocks the save and shows the error message you wrote. They are the simplest way to keep bad data out, with no code. This guide shows how to create one, 12 examples, and how to keep rules maintainable.
This post was first published in 2021 as "How to Create Validation Rules in Salesforce?". It has been rewritten for 2026 with more examples, bypass patterns, edition limits and testing advice.
How do validation rules work?
A validation rule's formula describes the bad case: when it returns true, the save is blocked and the user sees your message. Think of the formula as describing the bad case. Trailhead's validation rules unit puts it this way: when the rule returns true, the data the user entered contains an invalid value. A rule has four parts:
- Rule name: a unique API-style name, ideally with an error code.
- Error condition formula: true means block the save.
- Error message: what the user sees and how to fix it.
- Error location: the top of the page, or next to a specific field.
Rules run on every save path, not just the record page. Salesforce Help's validation rule considerations say they apply even when the fields aren't on the page layout or in an API call, and they are evaluated before Web-to-Lead and Web-to-Case create a record. Within a save, custom validation rules run after before-save flows and before triggers, so those can set a value the rule then checks; our order of execution guide shows exactly where.
How to create a validation rule, step by step
Open the object in Object Manager, click Validation Rules, then New, write the formula and message, activate and test.
- In Setup, open Object Manager and select the object, for example Account.
- Click Validation Rules, then New.
- Enter a rule name, such as ACC001_Account_Number_8_Characters, and a description that says when the rule applies.
- Write the error condition formula, for example LEN(AccountNumber) <> 8.
- Click Check Syntax to catch formula errors.
- Write the error message, for example "Account number must be 8 characters long [ACC001]", and choose the error location.
- Make sure Active is selected and save.
- Test in a sandbox: try to save a bad record, a good record, and an old record that you edit without touching the field.
12 Salesforce validation rule examples
These twelve formulas cover the most common needs: format checks, required-when rules, date logic and locked values. The first four come from Trailhead's examples; the rest use the same functions. Replace custom field names with your own.
| Requirement | Error condition formula |
|---|---|
| Account number must be numeric | AND(NOT(ISBLANK(AccountNumber)), NOT(ISNUMBER(AccountNumber))) |
| Date must be in the current year | YEAR(My_Date__c) <> YEAR(TODAY()) |
| Salary range no wider than 20,000 | (Salary_Max__c - Salary_Min__c) > 20000 |
| Close date not in the past for new or changed opportunities | AND(OR(ISNEW(), ISCHANGED(CloseDate)), CloseDate < TODAY()) |
| Amount required from the Proposal stage onward | AND(ISPICKVAL(StageName, "Proposal"), ISBLANK(Amount)) |
| Reason required when an opportunity is Closed Lost | AND(ISPICKVAL(StageName, "Closed Lost"), ISBLANK(TEXT(Loss_Reason__c))) |
| Discount over 30 percent not allowed | Discount__c > 0.30 |
| Closed Won opportunities can't change stage | AND(ISCHANGED(StageName), ISPICKVAL(PRIORVALUE(StageName), "Closed Won")) |
| A number field can't decrease | Seats__c < PRIORVALUE(Seats__c) |
| US zip code must be 5 digits or ZIP+4 | AND(BillingCountry = "US", NOT(REGEX(BillingPostalCode, "\\d{5}(-\\d{4})?"))) |
| Phone or email required on a contact | AND(ISBLANK(Phone), ISBLANK(Email)) |
| End date after start date | End_Date__c < Start_Date__c |
Salesforce Help also publishes sample rule libraries for accounts, opportunities, users and more; search Help for "sample validation rules" when you need a specific pattern. Those samples are formulas to copy, not a standard set to switch on, so the rules in your org are the ones your team created; that is why naming and descriptions matter.
A rule can reference formula fields as well as ordinary fields, for example to block a save when a calculated margin falls below a threshold. Keep in mind that a formula field referencing other objects counts toward the cross-object limit described below.
Best practices for maintainable validation rules
Keep one scenario per rule, use error codes, tell users how to fix the problem and protect existing data. From Trailhead's Optimize Validation Rules module, plus what we see in real orgs:
- One scenario per rule. Separate rules for Amount and Next Steps keep formulas simple and let each error point at the right field.
- Error codes. Prefix by object and number them (OPP001, OPP002) and put the code in the message, so a support ticket leads straight to the rule.
- Tell users how to fix it. "Close date must be today or later" beats "Invalid date".
- Show the error on the field whenever the rule is about one field.
- Pair ISCHANGED with ISNEW. Fields aren't detected as changed when a record is created, so ISCHANGED alone lets bad data in on create.
- Protect existing data. Use ISNEW or ISCHANGED so old records that break a new rule don't block users editing unrelated fields.
- Write descriptions that say when the rule applies.
How to bypass a validation rule for some users
Use a custom permission in a permission set and check it in the formula. Integrations, data migrations and admins often need to save records that users can't. Trailhead's bypass unit recommends a custom permission:
- Create a custom permission, for example Bypass_Opportunity_Validation.
- Add it to a permission set and assign that to the integration user or the people who need it.
- Wrap the rule:
AND(NOT($Permission.Bypass_Opportunity_Validation), CloseDate < TODAY()).
This beats checking $Profile.Name, which breaks when a profile is renamed. Two cautions: Salesforce has a known issue noting that rules referencing custom permissions can take longer to run than rules using custom settings, which matters on high-volume objects; and Trailhead suggests session-based permission sets, switched on by a flow only when needed, when users should only bypass temporarily, so that everyone follows the rules by default. Assign the permission through permission sets rather than profiles.
Validation rule limits by edition
As of November 2026, Salesforce allows 20, 100 or 500 active validation rules per object depending on edition.
| Edition | Active validation rules per object |
|---|---|
| Group | 0 |
| Contact Manager, Essentials, Professional | 20 |
| Enterprise, Developer | 100 |
| Unlimited, Performance | 500 |
Figures from Salesforce Help's active validation rules limit article, which adds that the limit can only be raised by upgrading the edition; check usage on the object's Limits page in Setup, which is also where to confirm the figure for the Core, Advanced and Max editions announced in September 2026, as the article lists the older edition names. Cross-object references in validation rules also count toward the object's limit of 15 spanning relationships across all formulas.
How to see all validation rules in your org
Each object's rules are listed under Object Manager → object → Validation Rules, with their active status. To review every rule at once, for example before a data migration, retrieve the ValidationRule metadata for all objects with the Salesforce CLI or a DevOps tool and read them in one place, or list them per object in Workbench through the metadata browser. Note any rule an integration or data migration will need to bypass.
Validation rule vs Flow vs required field
Use a required field for always-required values, a validation rule to block bad combinations, and a before-save flow to fix values automatically.
| Need | Use |
|---|---|
| A field must always have a value, everywhere | Required field on the field definition |
| A field is required only in some situations | Validation rule (or Dynamic Forms visibility for the UI only) |
| Block a combination of values with a message | Validation rule |
| Fix the value automatically instead of blocking | Before-save record-triggered flow |
| Check data in many related records | Flow or Apex trigger |
A page layout "required" setting only applies to that layout, not to the API, so it is not a data-quality control. See our Salesforce Flow guide for before-save flows.
Troubleshooting
Most validation rule problems show up in data loads, Web-to-Lead, old records and automation.
- A data load fails with your error. Fix the data, or give the load user the bypass permission. Don't deactivate the rule in production and forget to turn it back on.
- Web-to-Lead stops creating leads. A new lead rule is a common cause, because rules are checked before the lead is created.
- Users hit a rule on fields they can't edit. The rule fires on records that broke it before it existed; add ISNEW or ISCHANGED.
- Automation fails on save. Flows and triggers that update records also have to pass validation rules. Test automation and rules together.
Getting help
Techila is a Salesforce Summit Partner. Our managed services team audits and maintains validation rules, automation and data quality for Salesforce orgs. Talk to us about a data quality review.
Frequently asked questions
What is a validation rule in Salesforce?
A rule on an object that checks data when a record is saved. It contains a formula that returns true or false; if it returns true, the data is invalid, the record isn't saved, and the user sees the error message you wrote, either at the top of the page or next to a field.
Do validation rules run on data loads and API calls?
Yes. Salesforce Help says validation rules apply to new and updated records even when the fields aren't on the page layout or in the API call, so records that fail a rule also fail in Data Loader. They are also checked before Web-to-Lead and Web-to-Case records are created.
How many validation rules can an object have?
Active validation rules per object depend on the edition: 20 in Contact Manager, Essentials and Professional, 100 in Enterprise and Developer, and 500 in Unlimited and Performance, according to Salesforce Help. The limit can only be raised by upgrading the edition.
How do I let some users bypass a validation rule?
Create a custom permission, add it to a permission set, assign that to the users or integration user, and add NOT($Permission.Your_Permission_Name) to the rule's formula with AND. Avoid hard-coding profile names, which break when profiles change.
Should I use a validation rule or a Flow?
Use a validation rule to block invalid data with a clear message; it needs no maintenance beyond the formula. Use a Flow when you need to change data, create records or take actions. A before-save flow can also correct data automatically instead of asking the user to.