Validation Rules
Validation rules are a useful tool within Salesforce which allow for the enforcement of data integrity and business rules. They are used to ensure that data entered into a record meets certain criteria before it can be saved.
When creating validation rules, it is important to design them with the following best practices in mind:
- Validates a business process
- Ensure you are validating the correct business process and not just the data. This will help to ensure that the validation rule is relevant and useful, and reduce the risk of creating further data integrity issues.
- Considers other processes and mechanisms that may update a record
- Ensure that the validation rule does not interfere with other processes or mechanisms that may update a record. This includes automations and integrations.
- Reinforces data expectations in the user
- Ensure that the validation rule reinforces the data expectations of the system. This includes ensuring that the data is in the correct format and meets the required criteria for different periods in a record's lifecycle.
- Kept simple
- If the logic is complex or difficult to understand, it is also likely to confuse a user when it is triggered. Instead keep the logic simple and easy, using multiple validation rules, if necessary, to achieve the desired outcome.
- Provides clear actions to the user
- Ensure error messaging is concise and clearly states what the user needs to do to resolve the issue.
Entry conditions
Entry criteria for a validation rule is defined by providing a formula which evaluates the record and determines whether it passes validation or not. As validation rules are evaluated whenever a record is saved, it is important to ensure that the entry criteria are as specific as possible to avoid unnecessary validation errors.
Formulas should follow the guidelines set out here.
Example
Imagine we wish to prevent an Application record from being moved to the offer stage without a reference check having been completed.
Bad:
ISPICKVAL(Stage__c, "Offer") && Reference_Check_Completed__c == FALSE
The above example prevents the record from having the Stage field equal to "Offer" unless the Reference Check Completed field is set to TRUE.
This is not a good validation rule for several reasons:
- Prevents all changes to a record when the Stage field is set to "Offer" and the Reference Check Completed field is set to FALSE.
- Legacy records, such as those present in the system before the validation was enabled, will be locked until the field is updated.
- Business processes unrelated to the stage change are prevented - especially if the data is not reflecting the sequence in reality.
- E.g. An automation updating the "Last Interview Sentiment" field on application when the sentiment is provided at a later date.
- Integrations updating the record will fail.
Good:
ISCHANGED(Stage__c) && ISPICKVAL(Stage__c, "Offer") && Reference_Check_Completed__c == FALSE
The above example is a good example for several reasons:
- Considers the business process which is wanting to be enforced.
- E.g. The Stage field is only changed to "Offer" when the Reference Check Completed field is set to TRUE.
- Only evaluates the record when the Stage field is changed to "Offer".
- Legacy records are not affected by the validation rule.
- Other automations and integrations are not affected by the validation rule.
Validation rules cannot be bypassed. Ensure the impacts of this are strongly considered to avoid breaking automations and integrations that are unrelated to the validation rule.
Error messages
Error messaging is an important part of validation rules. It is the first thing a user will see when a validation rule is triggered, and it should provide clear and concise information about what the issue is and how to resolve it.
Error messages should follow the guidelines set out here.
User based exclusions
User based exclusions are a way to allow certain users to bypass validation rules. This is useful for system administrators or other users who need to perform actions that would otherwise be blocked by the validation rule. They should be used sparingly and only when absolutely necessary. They should be implemented in a way that does not compromise the integrity of the data or the system.
Custom permissions are usually a good vehicle for implementing user based exclusions. This allows for a more granular control over who can bypass the validation rule and also allows for easier management of the exclusions.
Apex / Flow validations
Sometimes more complex validations are required than can be achieved with validation rules, such as when validating the presence or values of related records. In these situations, Flow or Apex can be used instead of standard validation rules.
We recommend the use of Apex validations over Flow validations in all but the simplest of environments. Apex validation rules can be designed so that they can be bypassed when a situation calls for it, to preserve data integrity, such as data flowing in from an external system. This is especially simple by utilising the Seven20 trigger framework.