Salesforce Validation Rules – 5 Best Practices to Follow

There are many instances in a classic Salesforce environment where you may choose to use Validation Rules. For example:

  • An opportunity with a specific order number should always be closed.

  • An email address should be provided when a new lead is created.

  • Based on the client’s address, the account must be handled only by the designated sales office corresponding to it.

At all such scenarios, validation rules will further ensure that the data entering into Salesforce meets the set requirements. These may vary from fundamental business requirements to advanced needs for integrations. While dealing with Salesforce validation rules, you need to be careful and knowledgeable about them to optimize the same output. Here, we will discuss the validation rules best practices to get you better informed about it.

Salesforce validation rules best practices

  1. Do not ever directly create Salesforce validation rules in a production environment

As we know, Salesforce is a very easy platform to modify or customize in the production environment. If a sales administrator or another authority comes and requests the administrator as “whether you can change the settings to ensure that the contact title is mandatorily filled in?’, this can be done instantly. For this, the admin can just set a new validation rule and get it done. However, this approach may potentially tamper with another integration or may cause errors during the next deployment. There may be many problems like the test script, which may not fill in the roles while executing, or maybe integration with no data.

On the other hand, even if it may be a little more time to accomplish, it is always advisable to prepare the sandbox environment’s validation rules. You may test it to ensure that it meets the requirement without any possible repercussions before getting into production. Doing it the right way will ensure that all tests are run to detect any possible consequences or errors to be addressed before deployment.

  1. Run the validation rules as tapered as possible to avoid errors

This is an important thing but usually gets overlooked. We will check it out with a classic example here. Consider you want to integrate your Salesforce system with your financial management suite after one year of Salesforce implementation. To get it done, it should have an order number mandatorily. A validation rule to make order numbers mandatory may look like below.

This rule specifies that there should be an order number if a stage is to be closed. However, data-wise means that you may have the data for the whole year, which may not meet the expectations of the new standards. If you need to update the entire opportunity, then updates for the historical data may fail. So, it is better to skim down triggering criteria for when this validation rule kicks in. Here is a minor tweak suggested by Flosum with which we can achieve it with a minor change in the above rule as below.

This modified validation rule will check if there is an order number when a sale is closed. That means you cannot close any sales in hand without order numbers, but all the previously closed sales numbers will exist out there as such without order numbers. So, your validation rule is made as narrow as possible for the desired impact.

  1. DON’T use any IDs in validation rules

This is a mistake often made while using the record types, where people tend to use IDs. However, doing it that way may cause some troubles across the environments as these IDs change. If you use the Developer Name instead, it may remain the same across different environments. Also, using a custom label instead of a text string is a better approach to the same. You may also use Custom Permissions than the permissions sets. All these are better alternative approaches to using IDs in validation rules. This will make configuration stronger and help ensure that the rules work consistently when deployed in various environments.

  1. Notify when there are new validation rules

Let us again consider the order number mandatory for a closed sales scenario. When it is deployed into production, it may probably confuse the end-users. Without knowing it, they may operate as usual and hit an error they are not used to. In a live scenario, they may get panicky about not executing it as they used to. This may create some frustrations.

So, it is essential to notify any such changes in validation rules to the concerned end-users, IT, administration, and all others involved. Doing it in advance will further strengthen the argument to be created and tested in the sandbox, and everything will be ready by the time of its deployment into production. Whatever ways you follow to make this announcement, the key objective is to communicate it the right way and ensure that it is not being deployed as a surprise for anyone involved.

  1. Know the differences between validation rules and layouts

It is possible to mark a field mandatory through a validation rule or a page layout setting. However, if the rule is required to meet certain criteria to be activated, it is ideal to set the validation rule. Similarly, you can also insert data into the organization by using a data loader which will succeed if required only through the page layout.

In light of all the above advice, it is also very important to run thorough testing to ensure that the objectives are met without causing any repercussions from it. Sometimes, it may be that you enforce the validation on one file, and you do not see the exact output as you want. So, it may be ideal to try and go through the entire process and all objects in question. This approach will ensure that we do not run over any existing rules and automation. It is also essential to ensure the validation rule does not stop other running processes on the same object. The important thing to do is repeated testing with a multifocal approach to ensure that your time and resources are not wasted when the validation goes live.

Optimized by Optimole