Salesforce Validation Rules: Best Practices

Salesforce Validation Rules can be incredibly powerful. They can provide guidance for end users, ensure all of the necessary data is filled out, and they can verify that the data being entered is clean and useful. 

However, if not managed well, validation rules can easily get out of hand. End users may feel frustration when filling out fields, or conflicting logic may make it impossible to enter data at all. With every tool in Salesforce, it’s a good idea to follow best practices to ensure that you’re taking advantage of these tools to the best of your ability, so that you can keep the ball rolling throughout your business. 

So, what exactly are the best practices for Salesforce Validation Rules? Here’s a few that I highly recommend.

Make All of Your Validation Rules in a Dev Environment First – and Test them Thoroughly! 

This is the case for just about anything that you build, but with validation rules especially, this cannot be stressed enough! Make sure that your validation rules work as expected before putting them in production. Additionally, testing helps ensure that other processes, such as assignment rules and other field updates, don’t conflict with your validation rule. Finally, if you’re using regular expressions to validate fields such as phone numbers, be sure to test any and all possible user combinations to make sure the correct ones go through without error. 

Make Sure Your Error Messages are as Clear and Detailed as Possible. 

While you’re aware of how the validation rule you built works, your end users may not. That being said, one of the easiest roadblocks to stop all starts with making sure your error messages are clear. For example, an error message such as ‘Please re-enter using the required format’ isn’t the most helpful error message. What exactly should this field be formatted like? Instead, give the users as much detail as possible. 

Also keep in mind that with each validation rule, you get to choose where the error message appears – on the top of the page, or on the field itself. If your validation rule encompasses multiple fields, it may make the most sense to have your error be displayed towards the top of the page. However, if your validation rule is specific to one field, it’s probably for the best that you leave it on the field. If a user is unsure of why they were unable to save a record, they’ll waste time scrolling around on the page, especially if the page layout is more complex. Make sure they know what to do with clarity as soon as possible to avoid roadblocks and frustration. 

Know the Difference Between ISBLANK and ISNULL.

ISBLANK and ISNULL seem like they would do similar things, but knowing when to use them is very important, especially in the context of 

Formulas and validation rules.

ISBLANK and ISNULL both exist to determine if a field contains a value. However, ISNULL does not support text fields – it will always false, since text fields are never null. Therefore, if you’re creating a new formula, always use ISBLANK. 

However, ISNULL is still usable – but why? Since this is a legacy function, it’s still supported to support older functions. So if you’re maintaining an older org or come across it in your list of functions, you should know why it’s there and that ISBLANK should be used from now on. 

Consider Using Checkbox Fields with Validation Rules (evaluates to true or false) 

If you’re writing a validation rule that needs to evaluate true or false, consider the use of checkboxes, if it helps you simplify your validation rule. In general, keeping your validation rules (and the fields they’re comprised of) makes it easier to test, work with, and maintain them. 

Number Your Validation Rules 

A helpful trick for maintaining your validation rules is to number them when naming them. When naming validation rules, it can be tricky to name what exactly the validation rule does without getting too wordy. So when it comes to debugging that validation rule, it can be difficult to actually figure out what rule is firing. To mitigate this, place a number in front of all of the names of your validation rules. Then, at the end of the error message, write a message along the lines of “If you still need assistance, give your administrator this number: VALIDATION_NUMBER.” This will make it easy to trace the validation rule that is creating a conflict with minimal effort. 

Make Sure Users are Aware of New Validation Rules that are Coming

If end users are unfamiliar with having to enter certain criteria, or enter a certain way, it may be a confusing and frustrating change when that validation rule suddenly pops up. Before deploying a new validation rule to your org, make sure your end users are aware of it. Send out a release notification detailing what the change is, and how it will impact them from that point forward. This also gives end users to voice any questions or concerns they may have before potential problems arise. 

Consider Whether a Validation Rule is Really Needed, or if Setting a Field as Required Will Suffice

Does your field really need a validation rule? If a field will always be required, then it’s best to just set that field as required. However, if your field is only required after a certain stage in the process, for example, then a validation rule would make more sense. 

Sometimes, your “validation” could exist in an automation as well, such as a flow. Of these options, consider what exactly it is that you want the end user to do (or not to do). Should the user be prevented from entering bad data? Is it okay as long as data is entered? Or is it a little more complex than that?

Sometimes, the issue is not necessarily a validation rule, automation, or required field at all that will resolve the issue – sometimes, it’s the field type itself. Sometimes, getting the data quality you need just requires using the right field type – whether that’s an email field from the get-go, or using a restricted pick list to guarantee what types of data will come through. 

Consider Using Custom Settings in Place of Hard-Coded Values

If you’re working with IDs, such as record type IDs, or any kind of variable that could change in the future, don’t hard-code these – use custom settings instead. Creating a custom setting creates a variable that you can use across your org, in places like validation rules and flows. So if you ever have to change this value, you can do so in one place, and have the changes apply across your org – instead of having to remember where this ID lives, leaving room for things to break as you make updates. 

There’s a lot that needs to be considered when using validation rules, but hopefully these best practices for validation rules will help you get started! 

About Roycon
We’re an Austin-based Salesforce Consulting Partner, with a passion and belief that the Salesforce platform’s capabilities can help businesses run more efficiently and effectively. Whether you are just getting started with Salesforce or looking to realize its full potential, Roycon specializes in Salesforce Implementations, Salesforce Ongoing Support, and Salesforce Integrations, and Development. We’re the certified partner to guide the way to increase Salesforce Adoption, make strategic decisions, and build your Salesforce Roadmap for success.