In this blog, we will explore validation rules in-depth, understand the different types of validation rules in Salesforce, and learn how to implement them with examples. We will also look at some best practices for writing validation rules.
Learn about Salesforce by watching the video below
What are Validation Rules in Salesforce?
Validation rules are business rules that ensure the accuracy and integrity of your Salesforce data before it is saved. They check if the data entered by users meet the standards set by your organization before the records can be saved. A user-friendly error message is displayed if the data does not meet the specified criteria, thus prompting the user to correct it.
Validation rules in Salesforce can be applied at both object and field levels. You can specify whether the validation rule applies when creating or editing a record. Validation rules are helpful to ensure high data quality and integrity in Salesforce.
Types of Validation Rules
Validation rules are an essential aspect of maintaining data accuracy and consistency in Salesforce. There are different types of validation rules that can be used to ensure that the data entered into fields is valid and meets specific requirements. Here are some of the main types of validation rules:
A data type check ensures that the data entered into a field is of the correct type. The syntax for a data type check is as follows:
ISBLANK(fieldname) || NOT(ISPICKVAL(fieldname, "datatype"))
Where “fieldname” is the name of the field being validated, and “datatype” is the expected data type.
For example, if we want to ensure that the “Age” field is a numeric value, we can use the following code:
ISBLANK(Age) || NOT(ISPICKVAL(Age, "Number"))
A code check ensures that the data entered into a field meets certain criteria based on a specific code. The syntax for a code check is as follows:
fieldvalue < codevalue
Where “fieldvalue” is the value entered into the field being validated, and “codevalue” is the value used for comparison. For example, if we want to ensure that the “Price” field is less than $100, we can use the following code:
Price < 100
A range check ensures that the data entered into a field falls within a specific range. The syntax for a range check is as follows:
fieldvalue >= lowervalue && fieldvalue <= uppervalue
Where “fieldvalue” is the value entered into the field being validated, “lowervalue” is the minimum value in the range, and “uppervalue” is the maximum value in the range.
For example, if we want to ensure that the “Quantity” field is between 1 and 10, we can use the following code:
Quantity >= 1 && Quantity <= 10
A format check ensures that the data entered into a field matches a specific format, such as an email address or phone number. The syntax for a format check depends on the specific format being validated.
For example, if we want to ensure that the “Email” field is in a valid email format, we can use the following regular expression:
REGEX(fieldname, '^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$')
A consistency check ensures that the data entered into multiple fields is consistent with each other. The syntax for a consistency check depends on the specific fields being validated.
For example, if we want to ensure that the “Start Date” field is earlier than the “End Date” field, we can use the following code:
Start_Date__c < End_Date__c
A uniqueness check ensures that the data entered into a field is unique within a specific context, such as within a specific record type or object. The syntax for a uniqueness check depends on the specific context being validated.
For example, if we want to ensure that the “Username” field is unique within the “User” object, we can use the following code:
ISNEW() || Username__c != PRIORVALUE(Username__c)
A presence check ensures that a field is not left blank. The syntax for a presence check is as follows:
ISBLANK(fieldname)
Where “fieldname” is the name of the field being validated. For example, if we want to ensure that the “Name” field is not left blank, we can use the following code:
ISBLANK(Name)
A length check ensures that the data entered into a field meets certain length requirements. The syntax for a length check depends on the specific length requirements being validated.
For example, if we want to ensure that the “Description” field is between 10 and 100 characters, we can use the following code:
LEN(Description) >= 10 && LEN(Description) <= 100
A look-up validation rule ensures that a value entered in one field matches the value in
another field in a related object. The syntax for a look-up validation rule is as follows:
value1__c = related_object__r.value2__c
Where “value1__c” is the value entered in the first field and “related_object__r.value2__c” is the value in the corresponding field in the related object.
For example, if we want to ensure that the “Contact” field in the “Opportunity” object matches the “Primary Contact” field in the related “Account” object, we can use the following code:
Contact__c = Account__r.Primary_Contact__c
Function of Validation Rules
Validation rules are essential in ensuring the accuracy and consistency of data in Salesforce. Let’s explore the functions of each type of validation rule in more detail:
A data type check is implemented to verify if the input data matches the required data type for a field. This is necessary to prevent errors and maintain uniformity in data storage. For instance, if a field accepts only numeric values, a data type check ensures that no alphabetic characters are entered.
A code check is used to ensure that the data entered into a field meets certain criteria based on a specific code. This is useful for ensuring that data entered into a field is within a specific range or meets certain conditions. For example, a code check can ensure that a date entered into a field is not in the past or that a price entered into a field is not negative.
A range check is utilized to confirm if the data entered in a field is within the permissible range. This is crucial to ensure that the data entered falls within acceptable limits. For example, a range check can ensure that a discount entered in a field is between 0% and 50%.
A format check is used to ensure that the data entered into a field matches a specific format, such as an email address or phone number. This is useful for ensuring that data is entered in a consistent format. For example, a format check can ensure that an email address entered into a field contains an ‘@’ symbol.
A consistency check is implemented to verify if the data entered in multiple fields is consistent with each other. This is important to ensure that the data entered in different fields is related and valid. For example, a consistency check can ensure that the start date of a project is before the end date.
To guarantee that the data entered in a field is unique within a specific context, such as a record type or object, a uniqueness check is performed. This ensures that the data entered does not duplicate data in other fields or records. For instance, a uniqueness check can ensure that a product code entered in a field is not already in use.
To make sure a field is not left empty, utilize a presence check. Using this, you can make sure that all needed fields are filled in and the data is accurate. For instance, a presence check can confirm that a field has a customer’s phone number.
To make sure that the data supplied into a field adheres to specific length criteria, a length check is utilized. This helps to make sure that the data entered into a field isn’t excessively long or short. Using a length check, for instance, you can make sure the username you type into a field is between 6 and 20 characters.
A look-up validation rule is enforced to verify if the value entered in one field matches the value in another field of a related object. This ensures that the data entered in one field is associated with the data in another field or object. For instance, a look-up validation rule can ensure that a customer entered in a field is already present in the customer database.
Get 100% Hike!
Master Most in Demand Skills Now!
Yes, there are formulas that can be used in validation rules in Salesforce. These formulas are used to evaluate certain conditions and determine whether the data entered into a field is valid or not. Here are some examples of formulas that can be used in validation rules:
The IF formula is used to test a condition, return a value if it is true, and return a different value if it is untrue. To make sure the “Discount” field is less than or equal to 50%, for instance, apply the formula below:
IF(Discount__c <= 0.5, true, false)
When evaluating multiple conditions, the AND formula returns true if all conditions are satisfied and false if any condition is not satisfied. To make sure the “Start Date” and “End Date” fields are not empty, for instance, use the formula below:
AND(
NOT(ISBLANK(Start_Date__c)),
NOT(ISBLANK(End_Date__c))
)
The OR formula is used to evaluate multiple conditions and return true if any condition is met, and false if none of the conditions are met. For example, the following formula can be used to ensure that either the “Phone” or “Email” field is not blank:
OR(
NOT(ISBLANK(Phone__c)),
NOT(ISBLANK(Email__c))
)
To ascertain whether a record is being created for the first time, utilize the ISNEW function. This helps to guarantee that specific fields are necessary when a new record is created. For example, the following formula can be used to ensure that the “Name” field is not blank when a new record is created:
ISNEW() && ISBLANK(Name)
The PRIORVALUE function is used to retrieve the previous value of a field before it was updated. This is useful for ensuring that certain fields are not changed after they have been set. For example, the following formula can be used to ensure that the “Opportunity Stage” field is not changed after it has been set to “Closed Won”:
ISCHANGED(StageName) && PRIORVALUE(StageName) = 'Closed Won'
Validation rules and formula fields are both used to evaluate data in Salesforce, but they serve different purposes. The table below enumerates the same.
| Validation Rules | Formula Fields |
| These are used to validate data before it is saved to ensure data quality. | These calculate a value based on other fields and save it to the record. |
| They apply to one or more fields and prevent records from being saved if invalid. | They use a formula that returns a text, number, date, or Boolean value. |
| It uses a formula that returns either TRUE or FALSE. | It does not show the users any error message, as it fires after the record is saved. |
| They show the users an error message if the validation fails. | Values can be seen and filtered like regular fields. These are useful for reports and dashboards. |
Validation Rules vs. Workflow Rules vs. Approval Processes
Validation rules are best used for basic field validations; workflow rules are ideal for automation across fields and objects; and approval processes should be used for routing records for approval. These three can also be used together for advanced business logic.
Let’s compare validation rules with workflow rules and approval processes to understand when to use which tool:
- Use Validation Rules
- To validate field values before the record is saved.
- For basic validations that are independent of the record state.
- For easy implementation and maintenance of data.
- Use Workflow Rules
- To automatically trigger actions based on events like record creation or update.
- When triggering more complex logic that spans fields or objects.
- To send email alerts or tasks to users.
- Use Approval Processes
- To route records for review and approval before key changes are made.
- To allow different approvers and approval paths, based on record type or other attributes.
- When a sequential review of data by different approvers is needed.
- When the audit trail of all approvals is required.
Conclusion
Validation Rules in Salesforce are critical to ensure data accuracy and consistency within your organization. By implementing these rules, you can prevent erroneous or incomplete data from being entered into your system, which can lead to a host of issues down the line.