Validation Rules: 10 Examples Every Admin Should Know

Written by Mark Edcel Briones Lopez · Reviewed by Dedric Brown, Salesforce Product Manager and founder of Blazer2Role · Published October 12, 2026 · Facts verified October 12, 2026

• No computer science degree required
• Built for 3+ years of professional experience
• Made for hands-on practice in a Developer Edition org

Ask anyone what a Salesforce admin does all day and data quality comes up within a minute. Reps skip fields, type dates that already passed, and close deals with no reason attached. Validation rules are the admin's first tool for stopping that at the door, and they are one of the first things a hiring manager will ask you to build. This guide gives you ten Salesforce validation rule examples with the formula, the error message, and the reason each one exists, so you can practice them in your own org instead of memorizing syntax.

In this guide

1. How a Salesforce validation rule works
2. Examples 1 to 5: opportunity and date rules
3. Examples 6 to 10: contact, format, and lock rules
4. Five mistakes that make users hate validation rules
5. How to practice these before an interview
6. Questions people ask

How a Salesforce validation rule works

Salesforce describes validation rules as a check that the data a user enters meets the standards you specify before the record can be saved. The part that trips up beginners is the direction of the logic. You write a formula that describes the bad record, not the good one. When the formula returns true, Salesforce blocks the save and shows your message. When it returns false, the record saves normally.

Every rule is built from the same four parts:

• Rule name: a short label with no spaces, such as Closed_Lost_Needs_Reason, so the next admin knows what it does.
• Error condition formula: the logic that returns true when the data is wrong.
• Error message: the sentence the user sees, which should say what to fix.
• Error location: either the top of the page or next to one specific field.

A few platform limits are worth knowing before an interviewer asks:

• Active rules per object: 20 in Professional Edition, 100 in Enterprise Edition, and 500 in Unlimited Edition, per Salesforce's edition limits documentation.
• Formula length: 3,900 characters, with a compiled size limit of 5,000 bytes, per the same Salesforce limits documentation.
• Error message length: 255 characters or fewer, per the Salesforce Tooling API reference for the ValidationRule object.
• Permission needed: Customize Application to create or change a rule, per the Salesforce validation rule documentation.

Your own org's real numbers appear under Object Limits in Object Manager, so check there rather than trusting any article, including this one. To build a rule, open Setup, go to Object Manager, pick the object, choose Validation Rules, and click New. The Check Syntax button catches typos before you save.

Examples 1 to 5: opportunity and date rules

Each formula below describes the record you want to stop. Field names that end in __c are custom fields used as placeholders, so swap in your own. Several of these are adapted from the Examples of Validation Rules library in the Salesforce documentation, which is worth bookmarking.

1. Require a reason when a deal is lost

• Why it exists: without a loss reason, nobody can report on why deals fall through.
• Formula: AND(ISPICKVAL(StageName, "Closed Lost"), ISBLANK(TEXT(Loss_Reason__c)))
• Error message: Choose a Loss Reason before closing this opportunity as lost.
• What it teaches: picklists need ISPICKVAL or TEXT. A plain ISBLANK on a picklist field will not work.

2. Stop close dates in the past

• Why it exists: stale close dates wreck the forecast.
• Formula: AND(OR(ISNEW(), ISCHANGED(CloseDate)), CloseDate < TODAY())
• Error message: Close Date cannot be in the past. Pick today or a future date.
• What it teaches: ISNEW and ISCHANGED keep the rule from firing on old records every time someone edits an unrelated field.

3. End date must come after start date

• Why it exists: contracts and projects with reversed dates break every duration report.
• Formula: End_Date__c < Start_Date__c
• Error message: End Date must be on or after Start Date.
• What it teaches: the simplest rules are a single comparison. If either date is empty, the rule stays quiet.

4. Catch amount typos

• Why it exists: one extra zero on a deal distorts the whole pipeline dashboard.
• Formula: OR(Amount < 0, Amount > 10000000)
• Error message: Amount must be between $0 and $10 million. Check for a typo.
• What it teaches: OR fires when any one condition is true. The $10 million ceiling comes straight from the Salesforce sample and should be changed to fit your company.

5. Cap the discount a rep can enter

• Why it exists: finance sets a discount limit and wants it enforced, not remembered.
• Formula: OR(Discount_Rate__c < 0, Discount_Rate__c > 0.40)
• Error message: Discount Rate must be between 0% and 40%.
• What it teaches: percent fields are stored as decimals, so 40% is written as 0.40.

Examples 6 to 10: contact, format, and lock rules

The second set moves past opportunities into contact data, text formats, and rules that protect a record after a milestone.

6. Require an email or a phone number

• Why it exists: a contact nobody can reach is not much of a contact.
• Formula: AND(ISBLANK(Email), ISBLANK(Phone))
• Error message: Add an Email or a Phone number so this contact can be reached.
• What it teaches: AND fires only when every condition is true, which is how you require one of several fields.

7. Enforce the US ZIP code format

• Why it exists: territory assignment and mailing tools depend on clean ZIP codes.
• Formula: AND(MailingCountry = "USA", NOT(ISBLANK(MailingPostalCode)), NOT(REGEX(MailingPostalCode, "\\d{5}(-\\d{4})?")))
• Error message: ZIP code must be in 99999 or 99999-9999 format.
• What it teaches: REGEX checks a pattern, and text comparisons are case sensitive. Salesforce notes that a rule like this is not enforced when the country is typed as "usa".

8. Require ten digits in a US phone number

• Why it exists: dialers and texting tools fail on short numbers.
• Formula: AND(NOT(ISBLANK(Phone)), NOT(REGEX(Phone, "\\D*?(\\d\\D*?){10}")))
• Error message: US phone numbers need ten digits, such as (999) 999-9999.
• What it teaches: wrap format checks in NOT(ISBLANK()) so an empty field does not trigger the error. The pattern itself is the one Salesforce publishes.

9. Lock a won deal from being reopened

• Why it exists: once revenue is booked, moving a deal backward corrupts commission and finance reports.
• Formula: AND(ISCHANGED(StageName), ISPICKVAL(PRIORVALUE(StageName), "Closed Won"), NOT($Permission.Reopen_Closed_Won))
• Error message: Closed Won opportunities cannot be reopened. Ask Sales Operations for help.
• What it teaches: PRIORVALUE reads what the field held before the edit, and a custom permission gives chosen users a clean bypass. Our guide to profiles and permission sets explains how to hand that permission out.

10. Check a field on the parent account

• Why it exists: invoicing fails when a deal closes against an account with no billing country.
• Formula: AND(ISPICKVAL(StageName, "Closed Won"), ISBLANK(Account.BillingCountry))
• Error message: Add a Billing Country to the account before marking this deal Closed Won.
• What it teaches: a rule can reach up to a parent record with dot notation. This is called a cross-object validation rule.

Five mistakes that make users hate validation rules

A rule that blocks the wrong people at the wrong moment gets an admin more complaints than any other feature. These are the patterns to avoid.

• Writing the formula backwards: describing good data instead of bad data blocks every valid record. Read the formula out loud as "show the error when" before saving.
• Vague error messages: "Invalid data" tells the user nothing. Name the field and say what to do next.
• Forgetting imports and integrations: rules also run when records are saved through the API or a data import, so a new rule can quietly break a nightly sync. Check with whoever owns the integration first.
• No bypass plan: hardcoding a profile name into the formula works until someone renames the profile. A custom permission, as in example 9, is easier to maintain.
• Reaching for a rule when a simpler tool fits: if a field is always required, mark it required. If values need restricting, use a picklist.

Two more honest limits. Validation rules do not run when a record is deleted, and they do nothing about bad data that already exists until someone edits and saves that record. Format rules such as examples 7 and 8 are also written for US data. If your company sells internationally, they will reject valid addresses and phone numbers unless you add a country condition.

How to practice these before an interview

Validation rules show up in admin exam prep and in live build exercises, so reading formulas is not enough. If you are studying, our guide on passing the Salesforce admin exam on the first try covers how to turn topics like this into practice sessions. If you are interviewing, read what to expect from a hands-on admin interview test, because building a rule on a shared screen is a common task. A short plan that works:

1. Sign up for a Developer Edition org and create the custom fields used above, such as Loss Reason and Discount Rate.
2. Build examples 1 through 5 on the Opportunity object, one per sitting, and type each formula by hand.
3. Test each rule with one record that should fail and one that should save. Write down what happened.
4. Build examples 6 through 10, then create the custom permission and confirm the bypass works for one test user.
5. Write a one-page summary with screenshots and add it to your Salesforce portfolio projects, so you have something concrete to walk through in an interview.

Once you land the role, the same habits carry into your first 90 days as a Salesforce admin, where cleaning up old rules is often an early task. Blazer2Role sells the coaching and courses described here. We do not guarantee job placement. Knowing ten formulas will not get anyone hired by itself, and it matters far less than being able to explain why a rule exists. The Certification Track is $999 USD one time, and the Salesforce exam fee is not included in any tier. Questions about any of it can go to support@blazer2role.com.

Questions people ask

What is a validation rule in Salesforce with an example?
A validation rule is a formula on an object that stops a record from saving when the formula returns true. A common example is requiring a Loss Reason when an opportunity stage is set to Closed Lost. The user sees an error message you wrote, fixes the field, and saves again.

How many validation rules can you have per object in Salesforce?
Salesforce's edition limits documentation lists 20 active validation rules per object in Professional Edition, 100 in Enterprise Edition, and 500 in Unlimited Edition. Only active rules count toward the limit. You can see how many your org is using under Object Limits in Object Manager for each object.

What is the difference between a validation rule and a required field?
A required field must always have a value, on every record, with no conditions. A validation rule can require a value only in certain situations, such as when a stage changes, and it can also compare fields, check formats, and limit number ranges. Use the required setting when the answer is always yes.

Do validation rules fire on data imports and API updates?
Yes. Validation rules run when records are saved through the API and through import tools, not only when a person clicks Save. That is why a new rule can break an integration or a bulk upload. Lead conversion is a known exception unless the setting that requires validation for converted leads is turned on.

How do you bypass a validation rule in Salesforce?
The maintainable way is a custom permission. Create the permission, add a condition such as NOT($Permission.Your_Permission_Name) to the formula, and assign the permission through a permission set to the users who need the exception. Avoid deactivating the rule for everyone, since bad data can slip in while it is off.

Can a validation rule run only when a record is created?
Yes. Add the ISNEW function to the formula and the rule fires only on creation. To run it only on edits, use NOT(ISNEW()). To run it only when one field changes, use ISCHANGED with that field. Combining these keeps a rule from blocking edits to older records.