Seven Best Practices for Salesforce Validation Rules

These are classic examples of scenarios where you may choose to use Validation Rules in Salesforce. In short, validation rules ensure that your data in Salesforce meets the necessary requirements. It can be anything from business requirements to the requirements for your integrations.

The 7 Good Practices:

1. Never, ever create validation rules directly in the Production environment
2. Run rules as narrowly as possible
3. Remember to notify users when there are new rules
4. Be careful not to create too many rules
5. NEVER use specific IDs in a validation rule
6. Please be aware of the difference between layouts and validation rules
7. Do Testing, Testing and more Testing

Below, each practice is explained in detail:

1. Never, ever create validation rules directly in the Production environment

Salesforce is really easy to modify and edit in your production environment. If the sales manager or anybody from another part of the business just comes by and says: “Can you make sure that the contact’s title is always filled in?” An administrator can very quickly create a validation rule to make the manager happy… and potentially kill an integration or create errors for the next deployment.

It may sound crazy, but it can be anything from a test script that doesn’t fill in roles when it runs (and thereby prevents deployment), or it can be an integration, which does not have the data, etc.

It will take a bit longer, but always create your validation rule in a sandbox. Then test it out to make sure it does what it should, before deploying it to production. This will ensure that all the tests are run, and consequently, errors (if any) are detected before it is deployed to production.

(Bonus info: you can run all tests from your sandbox to catch any errors before you deploy)

2. Run rules as narrowly as possible

This rule is probably the one that gets overlooked most frequently. Take the example of the order number. This becomes a requirement one year after your initial Salesforce implementation, as you (now) want to integrate Salesforce with your financial system. To do this, it must always have an order number.

Such a validation rule could look like this:

And (
StageName = ‘ Closed ‘,
ISBLANK (OrderNumber)
)

The above means that, if  the “Stage” is closed, there must be an order number. However, this means that data-wise, you will have data for an entire year, which will never live up to the new standards. If you, all of a sudden, need to update all opportunities, all updates for historical data will fail. Here, it is better to narrow down the trigger criteria for: when the validation should kick in. With the above example, and a minor change, it is possible to avoid such an error. It will look like this:

And (
ISCHANGED (StageName),
StageName = ‘ Closed ‘,
ISBLANK (OrderNumber)
)

The rule, now, checks if there is an order number, when you close the sale. This means, you cannot close a sale without an order number, but, all previous closed sales can easily exist without it.

Therefore, run your validation rules as narrowly or as rarely as possible / acceptable for the desired result.

3. Remember to notify users when there are new rules

Again, the same scenario… there should be an order number for closed sales. If Advice #1 and #2 are followed, and it just gets deployed into production, there is a real risk of confusing the end-users. They will operate under business-as-usual activities, and then all of a sudden, they will get an error. They would not be able to complete the process as they are used to. This can create unnecessary frustrations (for the end users) with the process, system and possibly the IT Department.

An announcement on Friday, stating that from Monday onward they must fill in these new fields, can do miracles to reduce frustration. This further strengthens the argument to start in the sandbox and then deploy to production, so you ensure that everything is ready for Monday morning, and you would simply need to deploy. There are many alternatives to an announcement – it can be presented at a team meeting or by their immediate superiors. What matters is that it must be communicated.

4. Be careful not to create too many rules

This is a risk, which sometimes occurs out of the blue. First you need the ‘city’ field to be filled in, then ‘Reason for Lost’ and then there’s another rule, and another, and so on.

It can result in a process, which is so slow and rigid that it demotivates the end user. Therefore, always ask: Is the rule a “need to have” or just “nice to have”?

5. NEVER use IDs in a validation rule

This is often seen when using record types, where you simply use their ID. This can cause a bit of a headache across environments, because the IDs change. Take, for example, record types – use their Developer Name instead – this stays the same. Similarly, if it is possible to use a custom label, rather than a text string – do it – or to use Custom Permissions instead of profiles and permissions sets. These are better alternatives, which make the configuration more robust, and helps ensure that your rules work when you deploy from one environment to another.

6. Please be aware of the difference between layouts and validation rules

You can make a field mandatory either via a page layout or a validation rule. If a field is always required, this can be done via page layouts, but if it is only required under certain criteria, then setting a validation rule is the option at hand. Similarly, you can insert data into the organization, using a data loader and this will succeed if it is only required via a page layout; where as, it will fail when it is required via a validation rule, and the criteria are met.

7. Testing, Testing and more Testing

In the wake of the first advice, it cannot be stressed enough how important testing is. It may well be that you only enforced validation on a single field, and you see that it is doing exactly as you expect. However, at times it may be a good idea to try to go through the whole process for the object in question. This will help ensure that we do not or have not destroyed any existing automation or do not stop another process that touches the same object. Repeated testing can save a lot of time and resources in the end.