Explorations into Validation Rule Limits Per Object

alternate title:

How To Toe The Line Between
Obtaining the Cleanest Data Possible
Driving Your End Users Insane

Ahhhh, validation rules.

They bring out the best intentions in every salesforce.com admin upon discovery, after all, who doesn’t love clean data? These powerful tools are available on most out of the box objects* and all custom objects and can give an administrator the keys to the kingdom of clean, precise, calculated data for pristine reports and dashboards. Validation rules are beautiful in their simplicity, offering up a true or false result based on a formula or expression that will give your end user a green light or a  polite stop sign with a nicely worded error message, hopefully in a location that will offer up some reasonable error message that will aid said user to see the light shed upon the correct phrase based on their text field entry, a targeted percentage field value based on a pick list value, or perhaps something as simple as a required field based on the case when another field has a value.

The land of giddy, rule enforcing admins

However, once this Pandora’s Box of RULES is opened, administrators (and their corporate/executive sponsors) have a tendency to become giddy about the idea of validation rules, and want to enforce as much as they can on their objects at the record level to ensure that the *exact data* that they need is obtained through any means necessary. Two examples I’ve come across lately are  (and no offense to the posters, of course): Limits on Validation Rules and this question on the Developer Boards. Sometimes it’s a power trip, sometimes it’s a true need for clean data without having to fix any of it on the admin side, sometimes it’s pressure from executives to guide the end users as much as possible, but overall the creation and activation of validation rules on one object can sometimes go overboard.

And back to world of the end user trying to create an Opportunity record…

Where would the endless parade of validation rules leave end users, assuming that they were hit with 100 (plus?) validation rules when attempting to save one…lowly…record? Frustrated, overwhelmed, and possibly to the point where the user would throw up his/her hands and go back to entering the data in their trusty Google spreadsheet, because hey, no one will stop them from entering whatever they want to there (and other people can even add data to the sheet while I’m typing! – NIFTY!). Even if we consider the best case scenario where the validation rules have easy to follow instructions to populate the data in a record and they are displayed in the location that makes sense, once you get above 100 rules, the question is – is this rule 100% necessary to enforce in order to have this record saved?

So, without further ado, my tips to ensure that as an admin you get the data that you need without driving your end users insane:

  1. Use workflows if possible as an alternative to a validation rule – anything you don’t need to rely on the end user for entering manually and can instead automate through salesforce.com workflow rules? #Booyah!
  2. Communicate early (and often) with your end users and executive sponsor of the rule on the continued need for the validation rule. For this one, I’ll always suggest Chatter! You should have one method to communicate with your end users, and it’s extremely helpful if you can include a screenshot at a minimum or a process video to show what will cause the error message to display and how to fix the data in a record to ensure you do not receive the error. If it’s a conversation that you would rather keep private between the administrator and the executives asking for the rules, set up a Sales Operations private Chatter group and discuss away, just be sure to communicate any confirmed changes to the public Chatter group!
  3. Combine similar requirements into one validation rule if possible – self explanatory, and will hopefully help you out as an admin, just be sure to detail what you are looking for in the error message. This will also help you out when you are running into issues with active validation rules when testing or attempting to deploy Change Sets from a sandbox.
  4. Be extremely careful when setting up Cross-Object Validation Rules – this one drives end users particularly bonkers if they do not have a very precise error message referencing the object that is causing the validation rule error. If you want to enforce that Bob saves a Case record only when a Contact is not marked as Inactive, spell out that exact issue *in detail* in your error message. This validation rule type I try to restrict to no more than 2-3 per object to ensure that the  back and forth between related records is not too tedious, and does not cause an end user to just select any (most likely incorrect) value in order to save the object.
  5. Last but certainly not least – Display the error message on top of the field in question – I have seen too many error messages pop up at the top of the screen in row upon row of error messages, only to have the end users play the game of “find the correct section and specific field’ in order to update the data, if they even do it at all.

Just by following these simple rules, your end users will be happy (as you/your execs won’t be hounding them constantly to update their records with correct data) and everyone will have the clean, concise data they are looking to report on.

* We won’t go into the slightly heated topic of validation rules on Chatter objects…