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 precedence over the validation rules.

 

These instances are explained with further examples below:

Example:  

In a job portal, there is a validation rule that states, "If Job Salary is less than $50,000, show an alert, 'Sorry! This job does not meet the minimum salary requirement.'" This validation rule is set up to ensure that only job openings with a minimum salary of $50,000 or higher can be posted on the portal.

However, there is a scenario where this validation rule may be bypassed. If a job opening's salary is updated through an automated job feed from an external recruitment agency, the system automatically updates the job opening with the information from the job feed, including the salary. If the job feed data shows a salary of $50,000 or higher for a job opening, the system will update the job opening with this information, even if the validation rule would have triggered an alert due to the original salary being less than $50,000.

This means that despite the validation rule being in place, the system will accept and update the job opening with the new salary obtained from the job feed, overriding the validation rule and allowing the job opening to be posted on the portal, even if it does not meet the minimum salary requirement as per the original validation rule.

 

Following are the means for field update that will take precedence over the validation rule.

 

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, Recruit 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.

Example:

A recruitment agency uses a Recruit system to manage their job openings, and they have set up a validation rule to define the minimum years of experience based on the job location. The validation rule states that the minimum years of experience required cannot be less than 3 years for job openings in the USA, cannot be less than 5 years for job openings in the UK, and cannot be less than 2 years for job openings in India. The years of experience field is the primary field, and the job location field is a secondary field used in the validation rule.

The recruitment agency decides to update the job location for a group of job openings through a mass update operation in the Recruit system. They decide to update all the job openings' location to "India" as they are planning to expand their operations in India. However, they do not realize that the job location field is used in the validation rule for defining the minimum years of experience. As a result, all the job openings whose location is updated to "India" end up with different minimum years of experience, which do not comply with the validation rule.

For example, a job opening that originally required a minimum of 4 years of experience and was located in the USA gets updated to "India" as the job location during the mass update. According to the validation rule, the minimum years of experience required should not be less than 2 years for job openings in India. However, because the Recruit system does not restrict field updates of secondary fields used in a validation rule, the minimum years of experience required is not adjusted to comply with the validation rule, resulting in an unacceptable value of 4 years for a job opening with the job location set to "India".

This scenario highlights the importance of checking whether fields are used in a validation rule before updating them, especially when performing mass updates, API calls, or imports in a Recruit system for recruitment purposes, to avoid gathering unacceptable values in the module and ensuring data integrity in job openings management.