Validation Rules in Salesforce

Table of Contents

What Are Validation Rules in Salesforce?

Validation rules in Salesforce are automated checks that verify the data entered by users in records meets the standards you specify — before the record can be saved.

In simple terms, they act like a gatekeeper for your data quality. If a user tries to save a record that doesn’t satisfy the validation rule’s condition, Salesforce blocks the save and displays an error message explaining what needs to be corrected.

A validation rule contains a formula or expression that evaluates the data in one or more fields and returns a boolean value — TRUE (invalid data — block save) or FALSE (valid data — allow save).

For example:

Ensure all phone number fields follow a specific format (e.g., (XXX) XXX-XXXX)
Require that a “Closed Lost Reason” field is filled when an Opportunity is marked as Closed Lost
Prevent a Close Date from being set in the past

Validation rules are one of the five rule types in Salesforce, processed in this order:

Validation Rules → Assignment Rules → Auto-response Rules → Workflow Rules → Escalation Rules

Why Are Validation Rules Important?

Poor data quality is one of the biggest challenges organizations face in Salesforce. Duplicate records, missing fields, inconsistent formats, and incorrect entries can wreak havoc on reporting, automation, and business decisions.

Validation rules in Salesforce solve this at the source — the moment data is entered.

Here’s why they matter:

Data Accuracy — Prevent users from entering incorrect or inconsistent data
Business Logic Enforcement — Ensure data complies with your organization’s rules (e.g., discount cannot exceed 20%)
Reporting Reliability — Clean data leads to reliable dashboards and reports
Process Automation — Validation early in the process helps narrow down and automate downstream workflows
Compliance — Maintain audit trails and ensure critical fields are never skipped
CRM Predictive Analytics — Maintaining accuracy and consistency is vital for generating reliable predictions and insights from Salesforce Einstein

How Do Validation Rules Work?

Understanding the logic behind validation rules is critical for writing them correctly.

The TRUE/FALSE Logic

This is where most beginners get confused. Validation rules work opposite to how you might expect:

Formula Returns	What It Means	Action
`TRUE`	Data is INVALID	Block save, show error
`FALSE`	Data is VALID	Allow save

Think of it as: “Is the data bad? If yes (TRUE), stop the save.”

When Do Validation Rules Fire?

A validation rule triggers every single time there’s an attempt to save a record, whether:

A user creates a new record
A user edits and saves an existing record
Data is modified by an automated process, import, or integration

The "Yes/No Question" Mental Model

Salesforce describes it perfectly: validation rules are set up as yes/no questions where the answer must always be “No”.

For example:

“Is the Close Date in the past?” — The answer must be No to save.
“Is the Closed Lost Reason blank when the Stage is Closed Lost?” — The answer must be No to save.

Types of Validation Rules in Salesforce

1. System Validation Rules

These are pre-built rules that Salesforce automatically applies to maintain fundamental data consistency. You don’t create these — they exist by default. Examples:

Preventing future dates for certain historical records
Ensuring required fields aren’t left blank

2. Custom Validation Rules

These are created by Salesforce Admins to address your organization’s unique needs. Using Salesforce’s formula editor, you can define rules that:

Enforce specific business logic (e.g., unique account number formats)
Validate email address formats
Require certain fields based on picklist values or user roles
Prevent specific field combinations

You can create validation rules for:

Standard objects (Accounts, Contacts, Leads, Opportunities, Cases, etc.)
Custom objects
Campaign members
Case milestones

Components of a Validation Rule

Every validation rule in Salesforce has two main components:

1. Error Condition Formula (Rule Criteria)

This is the formula that evaluates the data. It uses Salesforce fields, functions, and operators to return TRUE or FALSE.

Example:

AND(
  ISPICKVAL(StageName, "Closed Lost"),
  ISBLANK(Closed_Lost_Reason__c)
)

This returns TRUE (and blocks save) when the Stage is “Closed Lost” AND the Closed Lost Reason is blank.

2. Error Message

When a record fails the validation rule, Salesforce displays this message to the user. A good error message:

Clearly explains what is wrong
Tells the user how to fix it
Is placed next to the relevant field (or at the top of the page)

Example:

“Please provide a Reason for Loss when the Opportunity is marked as Closed Lost.”

Additional Fields

Rule Name — A descriptive internal name (no spaces)
Description — Document what the rule does and why (important for maintenance!)
Active checkbox — Toggle to enable or disable the rule
Error Location — Choose to display the error at the top of the page or next to a specific field

How to Create a Validation Rule in Salesforce (Step-by-Step)

Follow these steps to create a validation rule in Salesforce:

Step 1: Navigate to Object Manager

Click the gear icon (⚙) in the top-right corner
Select Setup
In the Quick Find box, search for Object Manager
Click on the object you want to add a validation rule to (e.g., Account)

Step 2: Open Validation Rules

In the left sidebar, click Validation Rules
Click New to create a new rule

Step 3: Enter Rule Details

Enter a Rule Name (no spaces, use underscores)
Check Active to enable the rule immediately
Add a Description explaining the rule’s purpose

Step 4: Write the Error Condition Formula

In the Error Condition Formula box, write your formula
Use the Insert Field button to browse and select fields (avoids typos!)
Use the Insert Operator button for math and logical operators
Click Check Syntax to validate your formula before saving

Step 5: Set the Error Message

Type your Error Message
Select the Error Location: Top of Page or a specific field

Step 6: Save

Click Save to finish

Pro Tip: Always test your rule by creating a record that should trigger the error, and a record that should pass through. Confirm both behave as expected.

Key Functions Used in Validation Rules

Knowing the right functions makes writing validation rules much faster. Here are the most commonly used:

Function	Description	Example
`ISBLANK(field)`	Returns TRUE if field is blank/null	`ISBLANK(Phone)`
`ISPICKVAL(field, "value")`	Checks if a picklist field equals a value	`ISPICKVAL(StageName, "Closed Lost")`
`AND(expr1, expr2)`	Returns TRUE if ALL expressions are TRUE	`AND(ISBLANK(Phone), ISPICKVAL(LeadSource, "Phone Inquiry"))`
`OR(expr1, expr2)`	Returns TRUE if ANY expression is TRUE	`OR(ISBLANK(Email), ISBLANK(Phone))`
`NOT(expr)`	Reverses TRUE to FALSE and vice versa	`NOT(ISBLANK(Email))`
`LEN(text)`	Returns the length of a text string	`LEN(AccountNumber) <> 8`
`REGEX(text, pattern)`	Checks text against a regular expression	`NOT(REGEX(Phone, "\\d{10}"))`
`TODAY()`	Returns today’s date	`CloseDate < TODAY()`
`ISNUMBER(value)`	Checks if value is a number	`NOT(ISNUMBER(AccountNumber))`
`YEAR(date)`	Returns the four-digit year of a date	`YEAR(CloseDate) <> YEAR(TODAY())`
`TEXT(value)`	Converts a value to text	Used with picklist fields
`IF(condition, true, false)`	Returns different values based on a condition	Conditional logic in complex rules

10 Real-World Validation Rule Examples

1. Require Close Date in the Future (Opportunities)

Use Case: Prevent reps from entering a Close Date that has already passed.

CloseDate < TODAY()

Error Message: “The Close Date cannot be in the past. Please select a current or future date.”

2. Require Closed Lost Reason (Opportunities)

Use Case: Ensure reps explain why a deal was lost.

AND(
  ISPICKVAL(StageName, "Closed Lost"),
  ISBLANK(Closed_Lost_Reason__c)
)

Error Message: “Please provide a Reason for Loss when the Opportunity is Closed Lost.”

3. Limit Discount Percentage (Opportunities)

Use Case: Prevent reps from offering discounts greater than 20%.

Discount_Percentage__c > 20

Error Message: “Discount cannot exceed 20%. Please adjust the discount percentage.”

4. Validate Account Number Length (Accounts)

Use Case: Ensure all account numbers are exactly 8 characters long.

AND(
  NOT(ISBLANK(AccountNumber)),
  LEN(AccountNumber) <> 8
)

Error Message: “Account number must be 8 characters long.”

5. Validate Email Format (Leads/Contacts)

Use Case: Ensure email addresses follow a standard format.

AND(
  NOT(ISBLANK(Email)),
  NOT(REGEX(Email, "[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,4}"))
)

Error Message: “Please enter a valid email address.”

6. Require Phone When Lead Source is Phone Inquiry (Leads)

Use Case: Ensure phone is captured when the lead came via a phone inquiry.

AND(
  ISBLANK(Phone),
  ISPICKVAL(LeadSource, "Phone Inquiry")
)

Error Message: “Phone number is required when Lead Source is ‘Phone Inquiry’.”

7. Case Owner Must Be Assigned (Cases)

Use Case: Ensure a Case Owner is assigned when a case is picked up from a queue.

AND(
  NOT(ISBLANK(OwnerId)),
  CONTAINS(Owner.Name, "Queue")
)

Error Message: “Please assign the case to yourself before proceeding.”

8. Salary Range Validation (Custom Object)

Use Case: Ensure the difference between max and min salary doesn’t exceed $20,000.

(Salary_Max__c - Salary_Min__c) > 20000

Error Message: “Salary range cannot exceed $20,000. Please adjust the values.”

9. Website URL Format Validation (Accounts)

Use Case: Ensure websites use valid extensions.

AND(
  NOT(ISBLANK(Website)),
  NOT(
    OR(
      CONTAINS(Website, ".com"),
      CONTAINS(Website, ".org"),
      CONTAINS(Website, ".net"),
      CONTAINS(Website, ".edu"),
      CONTAINS(Website, ".gov"),
      CONTAINS(Website, ".io")
    )
  )
)

Error Message: “Please enter a valid website URL with a recognized extension.”

10. Require Description When Opportunity Amount Exceeds $50,000

AND(
  Amount > 50000,
  ISBLANK(Description)
)

Error Message: “A description is required for Opportunities over $50,000.”

Validation Rules for Different Salesforce Objects

Accounts & Contacts

Enforce consistent phone number formats
Require billing address fields for enterprise accounts
Validate email formats on Contact records
Restrict account number formats to your internal standards

Leads

Require the Phone field when Lead Source is “Cold Call” or “Phone Inquiry”
Validate email addresses before assigning to a rep
Require a Company name — prevent blank or single-character entries

Opportunities

Close Date must be in the future
Require a Closed Lost Reason when Stage = “Closed Lost”
Cap discount percentages
Require a Next Step when Stage moves to “Proposal/Price Quote”

Cases

Require a case description when Priority = “High” or “Critical”
Ensure Case Owner is a user (not a queue) when Status = “In Progress”
Require a resolution note when Status changes to “Closed”

Contracts & Orders

Validate contract end date is after start date
Require an approval signature field before setting Status = “Activated”

Best Practices for Validation Rules

Follow these best practices to write effective, maintainable validation rules:

Keep Rules Simple

Write one rule per business requirement. Complex multi-condition rules are harder to debug. Split complex logic into multiple simpler rules if needed.

Write Clear Error Messages

Your error message is what the user sees. Make it descriptive and actionable — not just “Invalid data.” Tell users exactly what is wrong and how to fix it.

Use the Insert Field Button

Always use the Insert Field button when building formulas. Many validation rule errors occur because field API names are slightly different than expected. This prevents typos.

Check Syntax Before Saving

Always click Check Syntax to verify your formula is valid before saving the rule.

Test Thoroughly

Test every rule by:

Entering data that should trigger the error (confirm it blocks save)
Entering data that should be valid (confirm it saves successfully)
Testing edge cases (e.g., blank fields, boundary values)

Document Your Rules

Add detailed descriptions to every rule. Future you (or the next admin) will thank you. Note why the rule exists, what it checks, and when it was created.

Deactivate During Data Imports

You can temporarily deactivate validation rules during data imports or migrations to avoid import failures. Remember to reactivate them immediately after.

Consider User Experience

Validation rules should guide users — not frustrate them. Avoid rules that enforce data a user cannot realistically provide (e.g., requiring “Annual Revenue” on a Lead when reps typically don’t have that information during prospecting).

Avoid Rule Conflicts

Salesforce processes validation rules in no specific order. Review all rules together to ensure they don’t conflict with each other or with workflow/process builder automations.

Use Bypass Logic for Admins

For rules that sometimes need to be bypassed by system admins, use a custom checkbox field (e.g., Bypass_Validation__c) and add: AND(NOT(Bypass_Validation__c), your_formula).

Common Mistakes to Avoid

Confusing TRUE and FALSE

This is the #1 mistake beginners make. Remember: your formula should return TRUE when the data is BAD (to block save). Many beginners write it the wrong way around.

Not Testing Enough

Always test both the passing and failing scenarios. A rule that blocks valid data will prevent users from saving legitimate records.

Vague Error Messages

Messages like “Invalid entry” leave users confused. Be specific: “Close Date must be today or in the future.”

Over-Validating

Too many restrictive rules create a frustrating user experience. Sales reps in particular will find workarounds or avoid Salesforce altogether. Only enforce what truly matters to your business.

Forgetting to Test Automations

If workflows, Process Builder, or Flows also update records, make sure your validation rules don’t block those automated updates.

Not Documenting Rules

Without documentation, it becomes difficult to understand why a rule exists months later — especially during troubleshooting.

Frequently Asked Questions (FAQ)

Q1: What is the difference between a Validation Rule and a Required Field?

A required field simply prevents saving unless the field has any value. A validation rule is more powerful — it checks the quality and content of the data using formulas. For example, a required field ensures the Phone field isn’t blank, while a validation rule can ensure the phone number follows a specific format like (XXX) XXX-XXXX.

Q2: What is the difference between a Formula Field and a Validation Rule?

A formula field is a read-only field that calculates and displays a value automatically. A validation rule checks whether the data entered meets certain conditions and prevents saving if it doesn’t. They use similar formula syntax, but serve completely different purposes.

Q3: Can I have multiple validation rules on the same object?

Yes! You can — and often should — have multiple validation rules on a single object. Each rule enforces a different business requirement. Salesforce processes all active rules when a record is saved. Just make sure they don’t conflict.

Q4: Can Validation Rules be bypassed?

By default, no — validation rules apply to all users, including System Administrators. However, you can build bypass logic using a custom checkbox field that only admins can check. Some admins also temporarily deactivate rules during bulk data imports.

Q5: Do Validation Rules fire on API data loads?

Yes. Validation rules fire on all record saves, including data loaded via the API, Data Loader, or third-party integrations — unless the rule is deactivated during the import.

Q6: What is the maximum number of Validation Rules per object?

Salesforce allows a maximum of 500 active validation rules per object in most editions. In practice, you should never need anywhere near this limit.

Q7: Can I reference fields from related objects in a Validation Rule?

Yes! You can use cross-object formula syntax to reference fields from parent objects. For example, on an Opportunity, you can reference the parent Account’s field using Account.FieldName.

Conclusion

Validation rules in Salesforce are one of the most powerful tools in a Salesforce Admin’s toolkit. They are the first line of defense against bad data — ensuring that everything entering your Salesforce org is accurate, complete, and consistent.

By mastering validation rules, you can:

Protect data quality at the point of entry
Enforce critical business processes automatically
Improve the reliability of reports, dashboards, and automation
Reduce manual data cleanup work for your team

Whether you’re just getting started or looking to write more advanced rules, the key is to start with your business requirements, keep your formulas simple, write clear error messages, and always test thoroughly.

Want to Master Salesforce Admin Skills Like This?

If this guide helped you understand validation rules in Salesforce, imagine what you could accomplish with a structured, certification-focused learning path.

The Salesforce Admin Certification Course at MyTutorialRack is designed to take you from beginner to certified Salesforce Admin — covering everything you need to pass the Salesforce Administrator Exam (ADM 201) and excel in real-world admin roles.

What You'll Learn:

Salesforce fundamentals and data model
Validation rules, workflow rules, and process automation
User management, security, and access controls
Reports, dashboards, and data analytics
Sales Cloud, Service Cloud, and AppExchange
Full exam preparation with practice questions

Why Choose MyTutorialRack?

Beginner-friendly, structured curriculum
Practical, hands-on exercises
Taught by experienced Salesforce professionals
Covers the latest Salesforce Admin exam topics
Lifetime access to course materials

Enroll in the Salesforce Admin Certification Course Now and take the first step toward becoming a certified Salesforce Admin today!

Found this guide helpful? Share it with other Salesforce learners and Admins. For more Salesforce tutorials, tips, and guides, keep following MyTutorialRack.