# Validation rules writing conventions

1. All Validation Rules MUST contain a Bypass<sup>2</sup> Rule check.
2. Wherever possible, a Consultant ***SHOULD*** use operators over functions.
3. All possible instances of `IF()` ***SHOULD*** be replaced by `CASE()`
4. Referencing other formula fields should be avoided at all cost.
5. In all instances, `ISBLANK()` should be used instead of `ISNULL`, as per [this link](https://help.salesforce.com/apex/HTViewHelpDoc?id=customize_functions.htm&language=en#ISBLANKDef).
6. Validation Rules ***MUST NOT*** be triggered in a cascading manner.<sup>1</sup>
    
    ### Examples

<table id="bkmrk-name-formula-error-m"><thead><tr><th style="width: 241.633px;">Name</th><th style="width: 316px;">Formula</th><th style="width: 138px;">Error Message</th><th style="width: 112px;">Description</th></tr></thead><tbody><tr><td style="width: 241.633px;">OPP\_VR01\_CancelReason</td><td style="width: 316px;">`!$Setup.Bypasses__c.IsBypassVR__c && TEXT(Cancellationreason__c)="Other" &&ISBLANK(OtherCancellationReason__c)`

</td><td style="width: 138px;">If you select "other" as a cancellation reason, you must fill out the details of that reason. \[OPP\_VR01\]</td><td style="width: 112px;">Prevents selecting "other" less reason without putting a comment in. \[OPP\_VR01\]</td></tr><tr><td style="width: 241.633px;">OPP\_VR02\_NoApprovalCantReserve</td><td style="width: 316px;">`!$Setup.Bypasses__c.IsBypassVR__c && !IsApproved__c && ( ISPICKVAL(Status__c,"Approved - CC ") || ISPICKVAL(Status__c,"Approved - Client") || ISPICKVAL(Status__c,"Paid") )`</td><td style="width: 138px;">The status cannot advance further if it is not approved. \[OPP\_VR02\]</td><td style="width: 112px;">The status cannot advance further if it is not approved. \[OPP\_VR02\]</td></tr></tbody></table>

<sup>1</sup> Cascading Validation Rules are defined as VRs that trigger when another VR is triggered. Example: A field is mandatory if the status is Lost, but the field cannot contain less than 5 characters. Doing two validation rules which would trigger one another would result in a user first seeing that the field is mandatory, then saving again, and being presented with the second error. In this case, the second error should be displayed as soon as the first criteria is met.

<sup>2 </sup>See [main Bypasses page](https://wiki.sfxd.org/books/best-practices/page/bypasses) for more info on the topic