A Salesforce validation rule is a formula that checks a record when someone saves it. If the formula returns TRUE, Salesforce blocks the save and shows the error message you wrote. If it returns FALSE, the record saves as usual. A good rule therefore describes the bad state you want to prevent.
This guide gives you 15 Salesforce validation rule examples you can paste into Setup, each with its object, formula, error message and error location. Further down you will find the troubleshooting list for rules that "do nothing", a bypass pattern for integrations and data loads, and the order in which Salesforce runs validation relative to flows and triggers.
If you would rather describe a rule in plain language and review the result in your sandbox, the Cirra AI Salesforce Admin MCP Server builds validation rules from a chat in the AI client you already use. We come back to that after the formulas.
How to read these examples
Every formula below is an error condition. It describes the situation that should be blocked. Field API names ending in __c are placeholders, so swap them for the API names in your org. Stage and status values such as "Closed Lost" are the Salesforce defaults, and your org may use different picklist values.
Create each rule in Setup under Object Manager, then the object, then Validation Rules. Write the formula, add a description for the next admin, choose where the error appears (next to a field or at the top of the page) and save the rule inactive until you have tested it.
Two habits make the examples below behave:
- Wrap picklist fields in
TEXT()orISPICKVAL(). A bare picklist reference in a formula returns an error. - Add
NOT(ISNEW())to rules built onISCHANGED()orPRIORVALUE()when you mean edits only. A brand-new record has no earlier value to compare against, so test those rules on a create and on an update.
Required field validation rules (1 to 4)
1. Require a loss reason when an opportunity closes lost
Sales leaders want to know why deals die, and a free-form reason field only helps if someone fills it in.
Object: Opportunity
AND(
ISPICKVAL(StageName, "Closed Lost"),
ISBLANK(TEXT(Loss_Reason__c))
)Error message: Choose a Loss Reason before you mark this opportunity Closed Lost.
Error location: Loss Reason field.
2. Require a state or province for U.S. accounts
Territory assignment and tax logic break when the billing state is empty.
Object: Account
AND(
OR(BillingCountry = "United States", BillingCountry = "USA"),
ISBLANK(BillingState)
)Error message: Enter a Billing State for accounts in the United States.
Error location: Billing State field.
3. Require at least one way to reach a contact
A contact with no email, phone or mobile number is a record nobody can act on.
Object: Contact
AND(
ISBLANK(Email),
ISBLANK(Phone),
ISBLANK(MobilePhone)
)Error message: Add an email address, phone number or mobile number for this contact.
Error location: Top of page.
4. Require an amount before the proposal stage
Forecasts drift when deals reach the late stages with no value attached.
Object: Opportunity
AND(
OR(
ISPICKVAL(StageName, "Proposal/Price Quote"),
ISPICKVAL(StageName, "Negotiation/Review")
),
OR(ISBLANK(Amount), Amount <= 0)
)Error message: Enter an Amount greater than zero before moving to a proposal or negotiation stage.
Error location: Amount field.
Format and data quality validation rules (5 to 7)
5. Check the ZIP code format
A regular expression catches typos before they reach your mailing list. This version accepts five digits or the ZIP+4 format.
Object: Account
AND(
OR(BillingCountry = "United States", BillingCountry = "USA"),
NOT(ISBLANK(BillingPostalCode)),
NOT(REGEX(BillingPostalCode, "[0-9]{5}(-[0-9]{4})?"))
)Error message: Enter a 5-digit ZIP code, or use the ZIP+4 format such as 94105-1234.
Error location: Billing Zip/Postal Code field.
6. Keep personal email domains out of lead records
Teams that sell to businesses often want a work address on every lead. This rule checks a short list of domains and matches the end of the address, so extend the list to match your market.
Object: Lead
AND(
NOT(ISBLANK(Email)),
OR(
RIGHT(LOWER(Email), 10) = "@gmail.com",
RIGHT(LOWER(Email), 10) = "@yahoo.com",
RIGHT(LOWER(Email), 12) = "@outlook.com"
)
)Error message: Use the lead’s work email address.
Error location: Email field.
7. Enforce an opportunity naming convention
Consistent names make reports and list views readable. This rule requires every opportunity name to start with the account name.
Object: Opportunity
AND(
NOT(ISBLANK(AccountId)),
NOT(BEGINS(Name, Account.Name))
)Error message: Start the opportunity name with the account name, for example "Acme Corp - Renewal".
Error location: Opportunity Name field.
Date validation rules (8 to 10)
8. Block a past close date on open opportunities
A close date in the past makes pipeline reports lie. The ISNEW() and ISCHANGED() checks mean the rule fires only when someone creates the record or edits the date, so older records stay editable for other reasons.
Object: Opportunity
AND(
NOT(IsClosed),
OR(ISNEW(), ISCHANGED(CloseDate)),
CloseDate < TODAY()
)Error message: Choose a Close Date of today or later.
Error location: Close Date field.
9. Require an end date after the start date
Object: Campaign
AND(
NOT(ISBLANK(StartDate)),
NOT(ISBLANK(EndDate)),
EndDate < StartDate
)Error message: The End Date must fall on or after the Start Date.
Error location: End Date field.
10. Keep close dates off weekends
The MOD() formula below counts days from a known Sunday (January 7, 1900) and flags Saturday and Sunday. Use it where your team commits to business-day close dates.
Object: Opportunity
AND(
NOT(IsClosed),
CASE(MOD(CloseDate - DATE(1900, 1, 7), 7), 0, 1, 6, 1, 0) = 1
)Error message: Pick a weekday for the Close Date.
Error location: Close Date field.
Stage control and approval validation rules (11 to 13)
11. Stop a Closed Won opportunity from moving backward
Once a deal is booked, finance and renewals depend on the record. This rule blocks any stage change away from Closed Won.
Object: Opportunity
AND(
NOT(ISNEW()),
ISCHANGED(StageName),
ISPICKVAL(PRIORVALUE(StageName), "Closed Won"),
NOT(ISPICKVAL(StageName, "Closed Won"))
)Error message: A Closed Won opportunity cannot move to an earlier stage. Contact Sales Operations to reopen it.
Error location: Top of page.
12. Require an executive sponsor on large deals
Object: Opportunity
AND(
Amount > 100000,
ISBLANK(Executive_Sponsor__c)
)Error message: Add an Executive Sponsor for opportunities over 100,000.
Error location: Executive Sponsor field.
Change the threshold to match your deal sizes. If your org runs multiple currencies, test how the comparison behaves for each one.
13. Let only approved users reassign account owners
Instead of checking a profile name, this rule checks a custom permission called Reassign_Account_Owner. You assign that permission through a permission set, which keeps the rule readable and lets you add or remove people without editing the formula.
Object: Account
AND(
NOT(ISNEW()),
ISCHANGED(OwnerId),
NOT($Permission.Reassign_Account_Owner)
)Error message: You do not have permission to change the Account Owner. Ask your Salesforce admin.
Error location: Top of page.
Service and case validation rules (14 and 15)
14. Require a resolution before a case closes
Object: Case
AND(
ISPICKVAL(Status, "Closed"),
ISBLANK(Resolution__c)
)Error message: Describe the resolution before you close this case.
Error location: Resolution field.
15. Block a closed case from reopening unless the user has permission
Object: Case
AND(
NOT(ISNEW()),
ISCHANGED(Status),
ISPICKVAL(PRIORVALUE(Status), "Closed"),
NOT(ISPICKVAL(Status, "Closed")),
NOT($Permission.Reopen_Cases)
)Error message: Only users with the Reopen Cases permission can reopen a closed case.
Error location: Status field.
Write error messages people can act on
An error message is the only documentation most users will ever read for your rule. Say what to fix, and where, in one sentence. "Choose a Loss Reason before you mark this opportunity Closed Lost" tells a rep exactly what to do. "Validation failed" sends them to the admin.
Choose the error location with the same care. A message next to the field points at the problem. A message at the top of the page suits rules that depend on several fields, such as the stage rules above.
Add a bypass for integrations and data loads
Integration users and one-time data loads often need to skip a rule. A custom permission handles this without a hard-coded user name.
- In Setup, create a custom permission named
Bypass_Validation_Rules. - Add it to a permission set and assign that set to the integration user or the admin running the load.
- Wrap the rule’s formula so the permission turns it off:
AND(
NOT($Permission.Bypass_Validation_Rules),
ISPICKVAL(StageName, "Closed Lost"),
ISBLANK(TEXT(Loss_Reason__c))
)Treat the bypass as an access decision. Assign it to as few people as possible and remove it when the job finishes. Our guide to permission set management covers how to keep those assignments tidy.
Why a validation rule is not working
When a rule does not fire, or fires at the wrong time, check these causes in order:
- The rule is inactive. Open the rule and confirm the Active box is checked.
- The formula returns FALSE. A validation rule blocks the save only when the formula returns TRUE. Read the formula as a description of the bad state.
- A picklist is referenced directly. Use
ISPICKVAL(Field__c, "Value")orTEXT(Field__c). - The rule depends on a previous value.
ISCHANGED()andPRIORVALUE()compare against the value before the save, so test them on an update as well as on a create. - Another automation changes the value first. A before-save flow or a before trigger can alter the field before your rule runs. The next section explains the order.
- The record is old. Salesforce checks a validation rule when a record is created or edited. Existing records that already break the rule stay as they are until someone saves them.
Where validation rules run in the order of execution
Salesforce documents the sequence of events for every save. Record-triggered flows that run before the save execute, followed by before triggers. Salesforce then runs most system validation again and runs your custom validation rules. Duplicate rules come next, then after triggers and the remaining steps, including record-triggered flows that run after the save, as listed in Salesforce’s order of execution documentation.
Two practical consequences follow. A validation rule sees the values after before-save flows and before triggers have changed them, so a flow that fills a field can satisfy a rule that checks it. A rule also applies to every save path, including the API and data tools, so a rule built for the page layout will block your integration as well. If you are weighing where to put logic, our article on Salesforce Flow debugging and maintainability covers how Flow fits alongside rules.
Test a validation rule before it reaches production
Build and test rules in a sandbox, then deploy them through your normal release process. For each rule, try four cases: a record that should be blocked, a record that should pass, a record that sits exactly on the boundary (an amount of exactly 100,000, for example) and a save made through the API or a flow if your org has them. Check the message text on each failure.
Salesforce also advises testing rules across each page layout in use, and checking any integration that writes to the object, because a rule applies to those saves too.
Build these rules with Cirra AI
Writing the formula is one part of the job. Setup still means opening the object, creating the rule, adding the error message, setting the location and activating it. Cirra AI works from the chat window you already use, whether that is Claude, ChatGPT or Cursor. You describe the business rule, and Cirra AI deploys a working validation rule to the org you connected through OAuth.
A request can be as plain as this: "In my sandbox, add a validation rule on Opportunity that requires a Loss Reason when the stage is Closed Lost, with the error shown on the Loss Reason field." Cirra AI creates the rule as your Salesforce user, so it can only make changes you could make yourself in Setup, and it documents each change. Review the result in the sandbox, run your test cases and deploy through your usual process.
Admins can also set Access Rules that decide how much of your org’s metadata Cirra AI may read or write in a given environment, and Salesforce’s own permissions still apply on top of them. Cirra AI supports Salesforce Enterprise Edition and up, and the free plan includes 100 credits a month.
Start Free Trial or Learn More about what Cirra AI can build and change in your org.
FAQ
What is a validation rule in Salesforce?
A validation rule is a formula attached to an object. It runs when someone saves a record. When the formula returns TRUE, Salesforce blocks the save and shows the error message you defined. When it returns FALSE, the save goes through.
How do I write a validation rule in Salesforce?
Go to Setup, open Object Manager, choose the object and select Validation Rules, then click New. Name the rule, write an error condition formula that returns TRUE for the bad state, enter an error message, choose where it displays and save. Keep the rule inactive until you have tested it in a sandbox.
Why is my Salesforce validation rule not working?
The most common causes are an inactive rule, a formula that returns FALSE for the case you are testing, a picklist referenced without ISPICKVAL() or TEXT(), and ISCHANGED() or PRIORVALUE() tested only on a new record. A before-save flow or trigger that changes the field first can also alter the outcome.
Can I bypass a validation rule for an integration user?
Yes. The usual pattern is a custom permission, added to a permission set and assigned to the user. You wrap the formula in NOT($Permission.Your_Permission_Name) so users who hold the permission skip the rule.
Do validation rules run on API calls and data loads?
Yes. Salesforce applies validation rules to new and updated records whether the save comes from the user interface or the API, so tools that use the API, including Data Loader, are subject to them. Use a bypass permission for planned data loads.
Do validation rules run before or after flows?
Custom validation rules run after record-triggered flows that run before the save and after before triggers. Record-triggered flows that run after the save execute later in the sequence.
Can Cirra AI create validation rules for me?
Yes. Cirra AI can deploy a validation rule in a connected Salesforce org from a plain-language description. It acts as the connected user, within that user’s permissions, and you review and deploy the result through your own process.
