Validation Rules are useful tools for ensuring your data is clean and that relevant information is captured in context by users. Instead of making fields required and possibly alienating your users and negatively influencing adoption, careful planning with validation rules can ensure you ask for essential data at the correct time.
When constructing a validation rule know that it is essentially an IF statement: A validation rule will fire if a certain set of circumstances (as described in the formula) is TRUE.
For example, when an Opportunity Stage is Closed-Won, then the Amount field cannot be blank. The validation rule would look like this:
ISPICKVAL(StageName, “Closed-Won”) && ISBLANK(Amount)
The user would be prevented from saving the record until they had entered a value in the Amount field.
Formula Functions that are very useful in Validation Rules include:
- ISCHANGED = has this field changed?
Useful to ensure when a field is changed related information is entered. It also saves the validation rule firing every time a record is saved if it is not necessary.
For example, when the validation rule is new and for the sake of performance and practicalities – we don’t want to include existing records that already have that value in this rule. - ISNEW = is this a new record?
This can help check when a record is new and a validation is not met that the record will be prevented from saving. This is key when the error should only be fired in context.
For example, certain fields need to be completed on an Account record only when Industry = Agriculture. - ISCLONE = is this a new cloned record?
Similar to ISNEW above. - PRIORVALUE = queries the previous value of a field.
For example, querying if the previous stage on an Opportunity was a certain value and compare it to the current value. This can be used to prevent users jumping stages if it is important that each Opportunity stage must be completed in sequence.
Considerations when creating or changing validation rules
When changing validation rules, check if any flows or processes create or update the records and check that these are not incompatible. If they are, they will fail. In fact anything that touches that record will throw an error (such as a roll up field will recalculate if you edit a child and if the parent record’s validation rule is fired, the child will not save). This can be deeply frustrating for users.
Where possible data cleanse / fix existing data so that it passes the validation rule. If this is not feasible, include a date criteria in the validation rule, eg for a rule that is added or edited from 7 Sept 2021:
(ISNEW() || DATEVALUE( createddate ) >= DATEVALUE(“2021-09-07”) ) && … )
Don’t exclude system administrators from validation rules – unless absolutely necessary. Validation rules which have a clause that means they do not apply to system administrators can lead to inconsistent data, which in turn can cause problems later on.