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

Visualforce Dispatcher Page

Sometimes, you might have a requirement that can’t be met using standard page layouts and you need to turn to Visualforce. But, maybe only a subset of the records need to use a Visualforce page and you’d prefer the others to stay using standard page layouts. The solution here is to use a Visualforce dispatcher page that redirects the user to the correct page depending on the criteria you set. There are several good posts about using a dispatcher page to redirect the user to different pages depending on specific criteria, including a classic from Jeff Douglas.

I haven’t seen a post that covers how to handle passing parameters from one page to the next. For example, if you are creating a child record from a related list, the new page prefills in the parent record values through the use of URL parameters. If you have a dispatcher page redirecting users, then the parameters can get dropped and your users don’t have as smooth of an entry process. Here’s a way to redirect and keep all the parameters.  I ran into a few oddities when implementing this. Hopefully the code below helps.

https://gist.github.com/dhoechst/85a37afef1f2428a3f56