Validation Rules in Salesforce ensure that users can only save records when the data entered meets specific criteria. Salesforce Admins define these rules using logical conditions that evaluate to either “true” or “false”. If a rule evaluates to “true”, the record can’t be saved, and Salesforce displays a custom error message explaining what needs to be corrected before the user can try again.
If that sounds a little technical, don’t worry. In this guide, you’ll learn what validation rules are, when to use them, how to create them, and how to work with more advanced concepts like syntax and bypass logic.
What Is a Validation Rule?
A validation rule is a way to check that the data being entered or updated on a record meets specific criteria before Salesforce allows it to be saved. Think of it as a gatekeeper: if the data doesn’t meet the standard you’ve set, the record gets blocked, and the user sees an error message explaining what needs fixing.
Salesforce caps the number of active validation rules per org, depending on your edition.
When Should I Use Validation Rules?
Use validation rules to maintain user input data or system modified records.
- User input data: Where users may be prone to making mistakes or cutting corners, or when you need data to be in a certain format.
- System modified records: Changes to data triggered by imports, automated processes, integrated systems, etc. will need to abide by validation rules*.
Having said that, validation rules are a safety net that these processes, ideally, should not bump up against. Admins should prepare/design automation/integrate systems respecting active validation rules. As we will see later, you can also write validation rules to bypass system modified records.
The most famous example is “Closed Lost Reason” on Opportunities. Imagine that you want to track why potential sales fell through. Your sales reps change the Opportunity Stage to “Closed Lost” but forget to select a reason – stop right there! The rep is prompted to fill in the field and then saves the record successfully.
A validation rule saves the day by preventing reps from closing an Opportunity while the “Closed Lost Reason” field is blank.
Keep in mind that validation rules are limited to the object they’re built on. If your requirement involves checking related or cross-object records, that’s outside what a validation rule can do declaratively. Consider checking out Flow’s Custom Error component, which can help you handle those more advanced scenarios.
Validation Rules vs. Required Fields
A question you might ask is, “Why not simply make the field required?” Required fields are ‘all or nothing’; you must complete the field for the record to be created. This creates a stricter but broader rule, while you can customize validation rules to kick in only under certain conditions.
In the Closed Lost Reason example above, we don’t require that field to be completed until the Opportunity Stage is being changed to “Closed Lost”. It wouldn’t make sense for the ‘Closed Lost Reason’ field to be required at any other stage of the pipeline. The ‘Stage’ value is the condition.
How to Create a Validation Rule in Salesforce
Validation rules can be broken down into three parts:
- Name and Description
- The Rule (the Error Condition Formula)
- The Error Message
Let’s see how the ‘Closed Lost Reason’ validation rule example looks from an admin’s perspective.
1. Name and Description
A clear name and description is very important – a small part of your org documentation that will benefit others who want to understand the purpose of the rule, and/or to modify it in the future.
Keep it short and simple! You may find that the description could be the same as the error message (step #3), but also add any context about who the rule was requested by, or what data issues the rule is preventing.
2. The Rule (the Error Condition Formula)
Setting up the validation rule itself is the trickiest part of this process to grasp. Even though I’ve worked with the Salesforce platform for years, I still need to refer back to validation rule reference guides (hopefully you, too, will bookmark this page!).
“Error Condition Formula” is the fancy name for the rule. Here is where you will tell Salesforce “if this happens | then that must be true“, for example:
“If the Opportunity ‘Stage’ is ‘Closed Lost’ | then the ‘Closed Lost Reason’ field must not be blank”
It’s easy to get confused when writing a validation rule formula, as they work differently compared to writing formula fields. This used to mess with my head, as validation rule formulas work backwards from what I’d expect. In formula fields, you’re writing the formula for what should happen, while in Validation Rules you’re writing the formula for what shouldn’t.
If the formula comes back TRUE, that’s Salesforce saying “yep, this is the bad scenario, block it”. It’s the opposite instinct from writing a formula field, where TRUE usually means “yes, show this”.
Here’s a tour around each of the buttons above the formula box.
Insert Field
This opens a pop-up that lists fields in the object you are writing the validation rule for.
Tip: Use this button! Sure, it does save time, but also many validation rule errors are caused by field names being slightly different than you may have guessed.
Remember, what you see on the record is the “Field Label”; Validation Rules and other formulas use the “Field API Name“.
In fact, Opportunity Stage is a perfect example. The API Name is “StageName”, not Stage:
Once you have located your field, use the “Insert” button to drop it into the formula.
Insert Operator
This opens a dropdown menu that lists operators, such as + (add), <> (not equal), etc.
You will be familiar with most because they follow standard mathematics syntax.
The key ones you need to know, which will stitch your formula statements together, are:
- && (and)
- || (or)
Insert Selected Function
This menu lists functions that you may be unfamiliar with.
There are different types of functions (view a full glossary here). Luckily, by selecting one, a description appears below the list.
The most commonly used functions are:
- ISBLANK(field) returns “True” if the field is blank.
- ISPICKVAL(field, specific picklist value) returns “True” if a picklist value in a field matches the picklist value in the formula.
- TEXT() converts a picklist value to text, a quirk for writing formulas that ask if a picklist field is blank/not blank.
- AND() returns “True” if all the items or functions are “True”.
- OR() returns “True” if any of the items or functions are “True”.
When to use && and ||, or AND() and OR()? We’ll come back to this later!
Check Syntax
This checks if the rule has been written correctly. Salesforce will even tell you what the problem is.
The most common issues are you:
- Are missing a parenthesis “)” somewhere.
- Misspelled a field name.
- Used the wrong function.
3. The Error Message
This error message will appear when a user does not meet the requirements set out by the validation rule. This is how the admin explains what the user must do to correct the record, before clicking “Save” again.
The error message location can appear at the top of the page or above the specific field causing the failed save. If there’s only one field the rule references, I recommend you locate the error message on the field (otherwise, locate it at the top of the page).
Finally, activate your rule by checking the “Active” checkbox!
Top Tips for Working with Salesforce Validation Rules
Bypass Logic for Validation Rules
Ideally, admins should prepare/design automation/integrate systems respecting active validation rules. However, having a way to toggle which users should bypass validation rules is very useful.
Step 1: Create a checkbox field on the User object.
You can call it “bypassVR__c”, “overpassVR__c”, or something more meaningful to you.
Step 2: Edit the User records.
Check the checkbox field for all users who should avoid the validation rules.
Step 3: Add the condition to validation rules.
Enter the following into every validation rule you create in your org:
&& NOT(OverpassVR__c)
While this trick is pretty straightforward and manageable, there’s also another way to bypass Validation Rules using custom permissions and have them managed via permission sets and permission set groups. You can read more about that here.
There’s also the alternative of bypassing using Profiles, which is especially handy if the users you want to grant this to all belong to the same profiles. You can reference a user’s Profile directly in the formula, using the $Profile global variable. This is especially useful if you don’t want to manage an extra checkbox field!
For example, if the profile you want to grant bypass privilege to is named “Power User”, add this to your validation rule:
$Profile.Name <> "Power User"
This tells Salesforce that if the user’s Profile is “Power User,” skip this rule.
Using && and ||, or AND() and OR()
&& and AND() as well as || and OR(), can be used interchangeably. The difference lies in the syntax and readability. Here is the same formula, written in different ways:
Basically, This && That is the same as AND(This, That) the same way This || That is the same as OR(This, That).
Which should you use? Answer: it’s mostly up to personal preference. However, if your rule contains multiple statements, you should use AND() and OR() because indenting and using separate lines will help identify syntax issues. && and || are typically used more as connectors between simpler expressions.
Summary
This guide has covered when to use validation rules and how to create them, as well as some tips for bypassing and common logic functions.
Hopefully you now have a solid understanding of how validation rules work, including that “TRUE = block it” logic that confuses admins early on. From here, you’re ready to start applying these formulas to your own org’s requirements, and if you want to see them in action, the next step is exploring real-world examples across Sales and Service.
Comments:
Comments are closed.