The Case Against Validation Rules

Salesforce validation rules have been on my mind recently, especially as I’ve been continuing to study some of my favorite things:

Streamlining your Salesforce is awesome

Streamlining your Salesforce is awesome

Some things these productivity methods and approaches to life have in common (basically) are:

  • The KISS principle: Keep it simple, silly! (Some people say stupid, but let’s be kind to ourselves)
  • Keep the main thing the main thing and
  • Discard, streamline, and focus to live a happy and productive life

So, for nonprofits with a limited budget and (possibly) rotating staff, do Salesforce validation rules make sense? I’m not sure. Here are a few reasons why I use them sparingly:

  • It’s better to spend your nonprofit’s limited resources on other areas of importance. For example, I’d much rather work with an organization that had a great system in place for preventing and managing duplicates and maintaining up to date contact information than one that uses validation rules to manage something that could possibly go wrong.
  • Organizational needs are likely to change (and they should!), and then validation rules become one more thing on the long list of a system administrator’s items to review: page layouts, profiles, record types, workflow rules, processes, Apex triggers, etc. – does the capacity cost outweigh the benefit gained by implementing the validation rule?
  • Importing data gets more tricky with validation rules in place (although thankfully you can now use a tool like tquila’s Salesforce Switch app to make this way, way easier {h/t Justin Edelstein for making it one of his Cloud Focus Weekly app picks of the week}).
  • They’re not the most user friendly, especially for nonprofit Salesforce administrators with less than 3 years experience (I mean seriously, check out some of these).

    Salesforce field types

    Salesforce field types

  • Often times you can use a field type instead to enforce data quality. We have so many great standard field options that I’m led to believe that in many instances validation rules are designed for ‘edge cases’, and again limited resources are better invested elsewhere.
  • Training staff is a better investment. Don’t get me wrong, I’m a huge fan of automation, but if staff don’t understand what fields they need to fill out and why before they submit a record for approval, for example, then they’re just going to get an error message every time (in this case, I’m assuming you have a validation rule to make some fields conditionally required).
    Clear processes and training really help!

    Clear processes and training really help!

    Training, transparency, and clear communication around your organization’s processes should be your first line of defense.

So, what do you think? What validation rules do you use that have really improved your Salesforce instance? I really want to know!



  1. Great post Missy! I wouldn’t say that I’m not a fan of validation rules, but I can say I see where you care coming form, I have seen orgs where admins not only require a field with FLS, but additionally have a validation rule for the same field, which is overkill in my mind. In addition, you’re right, it does make importing data a PitA, and causes some users to enter bad data just to save it.

    I do however think that well a well designed Validation Rule design can really do wonders. How? Glad you asked (even if you didn’t).

    1. Validation rules should be used when necessary, like when you need to lock an opp after it’s won, or keep the Close Date in the future. Having validation rules on fields that are not regularly monitored, meaning, since the Sales Reps have their weekly 1-on-1s with leadership for forecasting, then it makes sense to require a future Close Date as the field will be regularly monitored, but to have a validation rule on a field because it should have data but not for any reason, is a guaranteed way for you to get some crap data in your system.

    2. It is so important that before creating a rule, you understand the purpose of the rule and what rule you are actually creating. Especially when the rules become more complex, it is so easy to have a small misunderstanding that can kill the field you need by requiring one you didn’t need to.

    3. Although the Tquila toolkit rocks for the on/off, with data imports, I have found using a hierarchy custom setting for bypass access for all validation rules is a great way to see which rules apply to which users in a single place, giving you, the admin, an easy to follow on stop shop for updating access levels for all your rules.

    4. Using a naming convention that starts with an error code, and an error message that displays that error code, lets you troubleshoot so much faster.

    5. Rules need to be designed for a single field. When a user edits a record and has a message that says the Division, Title, Mobile, Address, and Manager fields are required, but they have some of the values and misread the error OR they have all the fields but the rule REALLY requires to have a phone with the format of (###) ###-#### and you have +1 ####-###-#####, your user will do whatever to make that record save.

    I guess to sum it up, you are right, validation rules are not often the best way to ensure the right data is populated, and they can be messy, especially those cross object rules, even for a seasoned admin. The power they have to not just require data but require data in dependant situations, they have when field requirements have dependencies, make them an extremely useful tool for any org, in the right situation. With great power comes great responsibility, and I think if there is another way to require the right data, it’s best to go with the other route instead of the VR.

    Not to mention, those freakin’ red errors annoy the heck out of me, as do the calls/emails where the end user only tells you that the red text says “Validation Error” and you need to hunt them down to find out what the validation error is. 😉

  2. Great post, Missy! I would say both/and for a lot of these, but that might be because my focus is on a pretty large and complex Salesforce instance with 600 users, where we definitely cannot rely on training alone to ensure a high quality of data. I would venture that most of our users are relieved by our validation rules, because it means that they are free to use the system and enter data, knowing that we have measures in place to guide them and to prevent errors before they even happen. We have quite a few validation rules on Opportunity and on on each of the rest of our most heavily used objects. Some of the places where we use validation rules:

    *Fields that rely on other fields that are not picklists so can’t be dependent picklists (i.e. if field A is filled out, please fill out field B)
    *Opportunity close date issues (e.g. close dates cannot be in the past)
    *Preventing edits on certain fields on closed opportunities (or Finance will bite your head off!)

    A thoughtful system of validation rules can and should provide users with guidance on what kind of data they should be inputting into the system. I do think, though, that all of the alternatives you listed should be *heavily* considered before implementing a validation rule – any time you put in validation, you run the risk of someone putting in bad data just to be able to save the record and move on, which obviously sends your data quality down and defeats those whole purpose of your rule in the first place!

    1. Thanks for this, Vered!!! This is so insightful and great. I really liked what you said about how there’s a risk of people entering bad data just to get past the validation rules!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: