Salesforce Validation Rules: A Developer's Guide

Understanding Salesforce validation rules

Validation rules are how you enforce data integrity on the platform. Admins and developers define criteria that user-entered or system-modified data has to meet before a record can be saved. Data that fails the criteria blocks the save and shows a user-defined error message.

Core functionality

A validation rule is a declarative tool that evaluates a logical condition, and the condition returns TRUE or FALSE.

• Condition evaluates to TRUE: the record cannot be saved. The data violates the rule.
• Condition evaluates to FALSE: the record saves. The data meets the rule's criteria.

Salesforce caps the number of active validation rules per org, and the cap varies by edition.

When to use validation rules

Validation rules keep data quality up, across user input and system-generated changes alike.

• User input data: where users make mistakes, overlook required fields or enter data in the wrong format. This is the common case.
• System-modified records: changes from imports, Apex triggers, integrations and other automation have to satisfy validation rules too. The better practice is to design those processes to respect the existing rules rather than bypass them without explicit intent.

The classic example is requiring a "Closed Lost Reason" when an Opportunity stage moves to "Closed Lost." Without the rule, sales reps can mark an opportunity Closed Lost without saying why, and your reporting accuracy suffers for it.

Limitations and alternatives

A validation rule is scoped to the object it was created on. It cannot check data across related or cross-object records declaratively. For that, look at Salesforce Flow's Custom Error component, which has more advanced error handling.

Validation rules vs. required fields

Both enforce that data is present. They differ in scope and conditionality:

• Required fields apply universally. The field has to be populated for the record to be created or updated.
• Validation rules apply conditionally. A field might be required only under specific circumstances, such as "Closed Lost Reason" only when Stage is "Closed Lost."

Creating a validation rule

A validation rule has three components:

1. Name and description. A clear, concise name and a detailed description are what keep the rule maintainable. The description should say what the rule is for, which data problems it prevents and any context that matters later.
2. Error condition formula. The logic Salesforce evaluates, written in Salesforce formula syntax. Unlike a formula field, a TRUE result here signifies an error and blocks the save.
3. Error message. What the user reads, explaining the error and how to correct it.

Error condition formula syntax and functions

The error condition formula is an expression Salesforce evaluates. If it returns TRUE, the validation rule fires.

The pieces you build it from:

• Insert Field: pick fields from the object. Always use the Field API Name, not the Field Label, so StageName rather than Stage.
• Insert Operator: the standard mathematical and logical operators, +, -, *, /, AND, OR, &&, ||, =, <>, ! and the rest.
  • && (AND): TRUE if both conditions are TRUE.
  • || (OR): TRUE if at least one condition is TRUE.
• Insert Selected Function: the library of built-in functions:
  • ISBLANK(field): returns TRUE if the specified field is empty.
  • ISPICKVAL(field, text_literal): returns TRUE if a picklist field matches the specified text value.
  • TEXT(picklist_field): converts a picklist value to its text representation, which you need for comparisons or ISBLANK checks on picklists.
  • AND(logical_expression1, ...): returns TRUE if all its arguments are TRUE.
  • OR(logical_expression1, ...): returns TRUE if any of its arguments are TRUE.

The Closed Lost Reason rule looks like this.

• Error condition formula:

  AND(ISPICKVAL(StageName, "Closed Lost"), ISBLANK(TEXT(LostReason__c)))
  

  Explanation: the formula returns TRUE when StageName is "Closed Lost" and the LostReason__c field is blank, which fires the validation rule.

• Error message: "Please select a reason for closing the Opportunity as Lost."

• Error location: above the LostReason__c field.

Check syntax

Run the "Check Syntax" button on every formula. The common failures are missing parentheses, misspelled field API names and incorrect function usage.

Activating the rule

Once the name, formula and message are in place, check the "Active" box to enable the rule.

Advanced concepts: bypass logic

Automation should respect validation rules, and sometimes you still need a bypass. There are a few ways to build one.

1. Custom checkbox field on User object

• Step 1: create a checkbox field such as Bypass_Validation_Rules__c on the User object.

• Step 2: check the box on the User record for anyone who needs the bypass.

• Step 3: append && NOT(Bypass_Validation_Rules__c) to your existing formula logic, so the rule fires only when the bypass checkbox is unchecked.

  Example:

  AND(ISPICKVAL(StageName, "Closed Lost"), ISBLANK(TEXT(LostReason__c)), NOT(Bypass_Validation_Rules__c))
  

2. Using custom permissions and permission sets

This one scales better and is easier to manage. Grant a custom permission such as Bypass_Validation_Rules_Permission through Permission Sets, then check for that permission inside the validation rule.

3. Using profiles

If everyone who needs the bypass shares a profile, reference it directly with the $Profile global variable.

To let "System Administrator" profile users past the rule:

AND(ISPICKVAL(StageName, "Closed Lost"), ISBLANK(TEXT(LostReason__c)), $Profile.Name <> "System Administrator")

The formula returns TRUE and blocks the save unless the user's profile name is not "System Administrator".

&& vs. AND(), || vs. OR()

&& and || suit simpler, more direct logical concatenations. AND() and OR() read better in complex rules with multiple conditions, because you can indent them and put each condition on its own line.

Both are functionally equivalent. The choice usually comes down to personal preference and how complex the rule is.