If you are here, we understand that you already know what is a Salesforce validation rule so let’s move to the next level.

First let’s talk about some best practices for validation rules in Salesforce:

• Don’t use hard coded Ids! For example, if you have to use a Record Type in the Validation Rule, never use the RecordTypeId field, use the RecordType.DeveloperName. The Developer Name doesn’t change between sandbox and production orgs.
• Consider using a bypass in your rules. This will help you when you don’t want to execute a validation rule under some conditions. I recommend you to use a hierarchy custom setting, with it you can disable every rules for your org or for one profile. This is especially useful for data migration. For example:

AND(!$Setup.ByPasser__c.ByPass_Validation_Rule__c,

Field__c == ‘value’,

!INCLUDES(Custom_Field__c, ‘Value’)

)

• Make them as small as possible. By small, I mean limit complexity and try to have all the logic in as few rules as possible.  
• Here you can view some others best practices recommended by Salesforce.

Based on the ‘Make them small’ best practice, Salesforce give us the possibility of using regex. With less characters you can create complex and complete rules.

For example, to validate the USA phone number, the validation rule should be something like:

!REGEX(Phone,"^((\\+1)?\\s?\\(\\d{3}\\)\\s?\\d{3}\\-\\d{4})?$")

This would return an error if the format is different from: (999)_999-9999 ó +1_(999)_999-9999

This level of validations will help you mostly with formats that you want to guarantee in your data quality. But, if what you need is more complex validations, perform checksum calculations or if the usage of regex is too complex, then we would recommend you to use our Axy Validator app that gives you many predefined validations like VAT, IBAN or Credit Card. And the best of all: IT’S FREE.

Take a look here or install it here!

Cheers  🙂

Axy7 Team.