PREFACE: This post is part of the Zero to Hero series.

Validation rules are kind of like the bumpers that go up along the gutter at the bowling alley. They guide the user down the right path by ensuring that appropriate fields are filled in at the right time and with the correct information. They ensure that the data entered by a user meets a minimum standard before the record can be saved.

There are a lot of use cases for validation rules. One popular use case is to create conditionally required fields. Let’s say that the business wants a picklist field to be required when two other non-required fields are populated. Because this is a conditional requirement, making the picklist required from the start defeats the purpose. However, a validation rule can make the picklist required when the conditions are met.

Other use cases include missing data, conflicting data and data formatting.

In today’s post, we’ll walk through the creation of a few validation rules in our dev orgs as it relates to our vehicle tracking tool we’ve been building, and then I’ll provide some other common validation rules that can be built in your company’s orgs.

Building a Validation Rule

If you’ve gone through the previous Zero to Hero posts, you’ve built out the functionality to track your vehicles and vehicle repairs with Salesforce. The validation rule we’ll build is based on the repair record. Here’s a look at a recent repair record I created for one of my vehicles.

Notice that the Repairs Suggested checkbox is checked, but the Suggested Repairs field is blank. Because the Suggested Repairs field is not required, and we only want it to be required when the Repairs Suggested checkbox is checked, a validation rule is the perfect solution. Here’s how to build it.

1. Click Setup | Create | Objects | Repairs | Validation Rules | New
2. In the Rule Name field, enter Require Repair Suggestions Text Box
3. Ensure the rule is marked as Active
4. Enter the following description: When the Suggest Repairs checkbox is checked, require a description in the Suggested Repairs text box.

Remember, that even though the description is not required, the best practice is always to fill it out so that at a glance, you know what this validation rule is supposed to do. Here is how the rule should look.

Now we’ll create the actual validation rule by writing a formula.

5. In the Error Condition Formula section, enter the following (modified to fit your field names):

AND(Repairs_Suggested__c = TRUE,
ISBLANK(Suggested_Repairs__c))

The AND operator says that all of the parameters must be true to evaluate the formula and return a True result. It’s only when the result of the formula is evaluated to True that the validation error message will display to the user. Let me break this formula down into everyday language:

“When Repairs Suggested checkbox is checked, and the Suggested Repairs text box is blank, trigger the rule.”

After creating the formula, be sure to press the Check Syntax button. This will tell you if there are any errors in the formula.

NOTE: Check Syntax will not tell you if your formula is correct – only that the formatting of the formula is correct including the proper use of operators. You’ll still need to test the validation rule to ensure it’s working properly.

With the formula created and validated via the Check Syntax button, it’s time to create the error message and determine the error message location.

6. In the Error Message section, enter the following into the Error Message field: Please enter a description of the suggested repairs.
7. The Error Location defaults to Top of Page. Let’s change it to Field and choose Suggested Repairs from the provided picklist.

Whenever possible, I prefer to have the error message display on a specific field. The only time Top of Page should be selected is if you know that multiple fields need to be satisfied as part of the validation rule. In that case, the error message should be very descriptive and include the field names that require an update.

Now, if I go back to my vehicle repair and try to save the record, this is what the validation rule should look like:

If you received this error message when updating one of your records, congratulations! You’ve just created a validation rule!

Validation Rule Tips & Tricks

Here is some helpful information on validation rules that may come in handy.

• Validations can be created on any object.
• Formulas are the only way to create a validation rule, but they are super powerful.
• The Check Syntax button doesn’t validate your actual formula. Be sure to test it first!
• Build your formula in a sandbox or dev org first. Otherwise, the rule may go live and impede the users workflow if things go wrong.
• When testing the validation rule, don’t test only the requirements of the validation rule. I’ve built a rule and occasionally found that the formula worked in reverse or wasn’t strict enough.
• Provide descriptive error messages. Users need to know how to fix the issue. Be sure the provided error message is descriptive enough to explain how to fix the issue.

Additional Resources

This was a fairly straightforward validation rule, but there are thousands of other validations that may be beneficial to your companies org. Here are some resources that I think will be helpful to you when evaluating how to write a validation rule, or provide some ideas on the types of validation rules to create.

1. Help & Training – Validation Rules Examples
2. Trailhead – Formula’s and Validations
3. Help & Training – Formula Operators and Functions Overview

My good friend Shell Black makes these awesome YouTube videos, and he has done one on Validation Rules. Here’s his video that I think will also provide some additional insight.

How are you using validation rules in your organization? Leave me a comment below – I’d love to hear from you!