Tricks all Salesforce Admins Need part 7 of 7 – When to Implement a Validation Rule #ForceFriday

Validation Rules are great! They force data quality, ensure users follow a process, and are part of a mature system. But, sometimes it can be difficult to determine when and where to implement a validation rule. Below I describe a framework (I know, my favorite) that will help guide what should be implemented as a Validation Rule.

Without further ado, I give you a Validation Rule decision framework.


When deciding if a Validation Rule is needed or not ask yourself three questions.

Should your field be required?

Is the field part of a step process?

Do you just need a warning message?


~ If a field needs to be require every time a record is edited then a Validation Rule should not be used. A Field Level requirement should be implemented.

~ If a field needs to be required sometimes (i.e. specific criteria) then a Validation Rule should be used.

~ A step process is any business process that has field dependent requirements. Validation Rules can be implemented to validate each step in the process, ensuring no steps are skipped.

~ Warning messages or “Soft Errors” aren’t supported by Salesforce just yet but please continue to vote for this idea – Validation Rules prevent the saving of a record whereas the warning message would allow a record save but display a warning based on your criteria. However, there are other options outside of Validation Rules which you can explore.

  • Use a Formula to display a dynamic message based on your warning criteria
  • Use a Visualforce page to display warnings
  • Use the Process Builder to push a Chatter Post (based on criteria) to users indicating the warning


** Note: Some Standard Salesforce Fields can’t be made required at the Field Level (e.g. Address Fields). The work around is to use a validation rule. You can vote for this idea if you run into this issue –