Validation Rules are effective on creating a record manually. However, when fields used in a validation rule (whether primary or secondary) are updated through other ways such as workflow update, and APIs, the field update takes precendence over the validation rules.
These instances are explained with further examples below:
Say you have a validation rule for the Deals module that says,
<<If Discount is > 20%, throw an error, "Sorry! This is an unacceptable discount.">>
This validation rule will be effective when you manually create a deal in CRM with a discount greater than 20%. However if the primary field, Discount, is updated via any of the following means, the field update overrides the validation rule.
That is, if the discount field is updated as 25% via a workflow field update, this workflow takes precendence, and as a consequence, the value will be accepted by the system despite the validation rule that is supposed to throw an error for values more than 25%.
Following are the means for field update that will take precedence over the validation rule.
| Means of field update in CRM | Field update details |
| Import | Updated on importing new leads or overwriting existing records |
| Workflow rules | Updated as a result of workflow action |
| Approval Process | Updated on approval or rejection of a record |
| Blueprint | Updated as a result of the After Transition settings. When you create a validation rule as well as Blueprint validation for the same field, and if the two conditions are different, Blueprint overrides the validation rule. That is, as long as the field is within a process, the Blueprint validation is applicable. When a record has exited a process, the validation rule is effective. |
| APIs | Updated via API updateRecords method |
| Mass update | Primary field used in a validation rule will not be available for mass update. |
This is an important note. When you try to update any of the secondary fields used in a validation rule through workflows, mass update, APIs or Import, CRM will accept the secondary field's values regardless of the conditions in the rule. As a result your data may gather unacceptable values despite the validation rule.
For example, you have a validation rule to define discounts based on region.
In this case, Discount is your primary field and the Regions become the secondary fields.
While Discount may not even show up on a mass update, Region will. If you decide to update all Regions to India, all your deals may end up with different discounts for "India", while your validation rule prescribes things differently - thus leading to unacceptable values in your module.
CRM will currently not restrict the field update of secondary fields used in a validation rule. Make sure you check whether fields are used in a validation rule before you update them.