Category Archives: Clicks not Code

Validation Rule Tips

When it comes to keeping your data in good shape, validation rules are a great clicks not code weapon to use in your arsenal. That said, validation rules can cause you a lot of grief if you don’t set them up with a few things in mind. Here are the things I’ve learned over the years with validation rules:

1. Use them as a last resort. Users don’t like trying to save a record and be told that a certain field is required. Where possible, use record types and page layout assignments to mark fields as required so the user sees the little red line indicating it is required. Dependent picklists are another option when one field is required when another is entered.

2. Make the error messages very clear to the user and think long and hard about where you want the error message to be displayed. It is best to display the error message on a field as it shows the user exactly where they need to make a change to save the record.

3. Try to keep the validation rule simple and focused on one problem. For example, let’s say on contact, you want to make a phone and alternate phone field required when a contact is marked as critical. Make two validation rules, one for each phone field and display the error message on the field. ¬†Your users will see exact instructions on where to enter data to correct the problem.

4. Add an error code to your error message. As your org gets more and more complicated, you will be so glad you have an error code to track down a validation rule that is preventing records from being saved. For example, you might have a validation rule on a rollup summary field. This rule might prevent the user from saving an object and you will be completely lost looking for a validation rule on that object, instead of looking at the parent object instead. My error codes include the name of the object and a number. I also name my validation rules with that error code so I can find it quickly in setup.

5. Add a kill switch to the validation rule. Sometimes you may only want the validation rule to prevent saves for some people. In that case, I like to use a hierarchical custom setting so I can turn off validation rules for the entire org, specific profiles or specific users. In your validation rule formula, you can reference hierarchical settings using $Setup.Setting_Name__c.Field_Name__c.

So, putting it all together, here is what I think a good validation rule should look like:

validation rule example