I love what the Salesforce platform can do. One of its many strengths is validation rules, which allow you to define custom logic and error messages to ensure data integrity. These are a great asset for any Salesforce Administrator’s quiver, and, when used properly, can be very effective. However…just because you can, does not mean you should use a validation rule every time.
I’ve got two reasons why:
#1 – Validation rules are hidden. A user does not know that they are there, lurking and ready to yell at them, until they click “save” on a record. That’s when they get an error message and can resolve the error. These messages are especially frustrating when the criteria are complicated and when there are multiple validation rules in place that fire off one after another. I can’t count the number of times that a user just blams “ASDF” into a text field because a validation rule says it’s required. We like to think they will help data be better, but, in reality, the users will do what they need to do to keep moving. (As a corollary to this, keep the number of required fields as small as possible!)
#2 – Validation rules exist at a very low level in the system, meaning that at the API level they are still present and not allowing record saves. In other words, they could break an integration, workflow rule, flow, or even test coverage for code in your org. This last piece is very important–if test coverage is broken by validation rules, it may present deployment challenges in the future if you try to install new packages or any more custom code. I’ve seen this blow deployments, deadlines, and budgets. Don’t be that admin!
So, how can you avoid validation rules? First, consider why you want to institute a validation rule. Most of the time, I hear an answer like, “to prevent the users from saving bad data.” If that’s the case, check out these methods that are effective in preventing bad data without requiring a validation rule.
Method #1: Training, training, training.
Train your users on what a good record is. Once good habits are established, users will be more diligent about inserting “good” data. If there are a few key items that you’ve considered targeting with a validation rule, target with a report first. Use reports or list views to monitor data health and determine if training can minimize the errors. At the very least, you’ll know who is inserting the offending data so that you can do some targeted refresher training.
Method #2: Have great page layouts.
Lightning Experience is changing the rules here, and if you have it turned on already that is great. But general best practice is that you don’t want to overwhelm users with overly long or complex layouts, using sections and blank spaces to logically group fields so it’s easier to make things compliant. Finally, use dependent picklists to help guide the user through choices and create better data.
Method #3: Related to the whole “great page layouts” topic, make fields required at the page layout level.
Instead of using a validation rule that dictates that a field must be required, just do it at the page layout level. That gives you the best of both worlds, allowing you to ensure that fields are being populated without running the risk of breaking test code/integrations.
Method #4: Make it obvious if data is good.
I LOVE image formula fields for this. If you were going to write a validation rule that required a loss reason on an opportunity, turn to image formulas instead. Use one which renders a big red X on the page (and reports and list views) if the opportunity is closed/lost and does not have a loss reason. Nobody likes the “Mark of Shame” on their records, and, generally speaking, bad data exists not because users don’t care, but because they’re in a rush. Bringing attention to bad data motivates users to avoid generating it.
Finally, if you MUST use a validation rule, follow these guidelines:
- Make it as small as possible. By small, I mean limit complexity and try to have all the logic in as few rules as possible to prevent multiple cascading errors for users.
- Consider a bypass. And, here’s a neat trick: If you are employing validation rules, consider adding “circuit breakers” to the rules. By including system variables and referencing user details, it’s possible to have the rules “bypass” users that meet certain criteria. For example, if the user is the Integration User, render a false result. This way, you can still have your rules and enable the integration to insert data as needed. There are quite a few blog posts and articles written about bypassing validation rules if this topic interests you!
- TELL YOUR DEVELOPERS! If you’re working with any developers or Salesforce partners, tell them what you’re doing. I’ve been in active projects recently where everything started failing due to an overzealous admin going to town on validation rules. Talk about your strategy first, and test in a sandbox before adding to production!
Do you have any other tips or stories about validation rules? Leave a comment, and happy Admin-ing!
