Applying Validation Rules on DateTime Fields in Salesforce

[Linux Hint]

In Time Series Analysis, DateTime is a necessary attribute to predict the Sales across each month with respect to every year. In order to follow-up with this data, we need accurate date/date-time samples. In Salesforce, the correct entry of date-time is taken care by specifying the validation rules on the object. Let’s see how to apply the different validation rules on Date and DateTime fields on Salesforce objects.

Basically, a validation rule in Salesforce prevents irrelevant/unwanted data before entering into the Salesforce system. Using some Date/DateTime functions, we can fire the validation on the User Interface such that the user enters the correct data.

Validation Rule Creation

1. Rule Name – Specify the validation rule Name (without special characters).

2. Active – If it is unchecked, the validation rule is inactive. It is active by default.

3. Description – It is optional to specify about the validation rule.

4. Error Condition Formula – It is an editor to specify the formula expression/s that evaluates to True/False.

5. Error Message – It displays the specified message on the Salesforce Object UI.

6. Error Location – If your validation rule checks several fields, display the error message at the top of the page by selecting “Top of Page”. If you want to display your error message next to the field, the user should be correct. Select “Field” and choose the field where you want to display the error message next to.

Let’s look at different Date/DateTime validation rules that use different formula functions/expressions with examples.

Example 1:

In this example, we write a validation rule on the “Campaign” object on the “End Date” field. If the year in the End Date is other than the current year, we fire this validation rule with an error message which is “Campaign End Date must be in the Current Year” that is displayed on the field itself.

Formula:

First, we extract the year from the “End Date”. The YEAR() function is used to get the year from the “End Date”. TODAY() is used to get the current date. From this, we also get the year using the same function. After that, we compare the “End Date” year and today’s year using the not equal operator (<>). If the “End Date” year is not equal to the current year, this validation will be fired.

YEAR( EndDate) <> YEAR (TODAY())

Test Record:

Go to the App Launcher and search for “campaigns”. Then, create a campaign named “Linuxhint DM Campaign to Top Customers” and test the following scenarios:

Positive: No validation is thrown since the “End Date” is within this year (2023).

Negative: A validation is thrown since the year of the “End Date” is 2027.

Example 2:

In this example, we write a validation rule on the “Campaign” object on the “End Date” field. If the year in the “End Date” is other than the current month, we fire this validation rule with an error message which is “Campaign End Date must be in the Current Month” that is displayed on the field itself.

Formula:

First, we extract the month from the “End Date”. The MONTH() function is used to get the month from the “End Date”. TODAY() is used to get the current date. From this, we also get the month using the same function. After that, we compare “End Date” month and today’s month using the not equal operator (<>). If the “End Date” month is not equal to the current month, this validation will be fired.

MONTH( EndDate) <> MONTH(TODAY())

Test Record:

Consider the previous record that is used in Example 1 and test the following scenarios:

Positive: No validation is thrown since the “End Date” is within this month (June).

Negative: A validation is thrown since the month of the “End Date” is August.

Example 3:

In this example, we write a validation rule on the “Account” object on the “Account Start date” and “Account End date” fields. First, we need to create these two custom fields of date type. If the “Account Start date” is ahead of the “Account End date”, we fire this validation rule with an error message which is “Account End Date Cannot be Before Account Start Date” that is displayed on the page.

Formula:

We simply use the “greater than” operator that checks if the “Account Start date” is greater than the “Account End date”. If it is True, the validation will fire. Otherwise, it won’t fire.

Account_Start_date__c > Account_End_date__c

Test Record:

Create an account named “Linux Hint Account” and test the following two scenarios:

Positive: No validation is thrown since the “Account Start Date” is less than the “Account End Date”.

Negative: A validation is thrown since the “Account Start Date” is greater than the “Account End Date”.

Example 4:

Again, we write a validation on the same fields (Example 3). First, deactivate the previous validation rule. If the difference between “Account End date” and “Account Start date” is greater than 10 days, we fire this validation rule with an error message which is “Difference between Account End Date & Account Start Date must be less than 10” that is displayed on the page.

Formula:

First, we subtract the “Account Start date” from the “Account End date”. Then, we compare the result using the greater than operator (>) with 10. If it is True, the validation will fire. Otherwise, it won’t fire.

(Account_End_date__c - Account_Start_date__c) > 10

Test Record:

Consider the same record for testing:

Positive: No validation is thrown since the difference between the “Account End Date” and “Account Start Date” is less than 10.

Negative: The validation is thrown since the difference between the “Account End Date” and “Account Start Date” is not less than 10.

Now, we apply the validation rules on the Date/Time fields. First, we need to create two fields which are “Contact First” & “Contact Last” on the “Contact” object of Date/Time type.

Example 5:

Let’s write a validation rule on the “Contact” object on the previous two custom fields. If the “Contact First” DateTime is ahead of the “Contact Last” DateTime, we fire this validation rule with an error message which is “Contact First can’t be greater than Contact Last” that is displayed on the page.

Formula:

The DATETIMEVALUE() is used to get the DateTime value. We simply use the “greater than” operator that checks if the “Contact First” is greater than the “Contact Last”. If it is true, the validation will fire. Otherwise, it won’t fire.

DATETIMEVALUE(Contact_First__c) > DATETIMEVALUE(Contact_Last__c)

Test Record:

Create the following contact and test the two scenarios:

Positive: No validation is thrown since the “Contact First” is less than the “Contact Last”.

Negative: A validation is thrown since the “Contact First” is greater than the “Contact Last”.

Example 6:

Now, consider only the time part. If the “Contact First” time is ahead of the “Contact Last” time, we fire this validation rule with an error message which is “Contact First Time should not be greater than Contact Last time” that is displayed on the page.

Formula:

The TIMEVALUE() is used to get the time only. We simply use the “greater than” operator that checks if the “Contact First” time is greater than the “Contact Last” time. If it is true, the validation will fire. Otherwise, it won’t fire.

TIMEVALUE(Contact_First__c) > TIMEVALUE(Contact_Last__c)

Test Record:

Create the following contact and test the two scenarios:

Positive: No validation is thrown since the “Contact First” time is less than the “Contact Last” time.

Negative: A validation is thrown since the “Contact First” time is greater than the “Contact Last” time.

Example 7:

We extract the date part from the “Contact First” and compare it with today’s date. If both are different, we fire this validation rule with an error message which is “Contact First Time should be today” that is displayed on the page.

Formula:

The DATEVALUE() is used to get the date only. We simply use the not equal (<>) operator that checks if the “Contact First” date is not equal to today’s date, If it is true, the validation will fire. Otherwise, it won’t fire.

DATEVALUE(Contact_First__c)<> TODAY()

Test Record:

Create the following contact and test the two scenarios:

Positive: No validation is thrown since the “Contact First” date is today (June 2, 2023).

Negative: A validation is thrown since the “Contact First” date is not June 2, 2023.

Conclusion

We learned how to fire the validation rules on the Date and Date/Time fields on the Salesforce standard objects which are Accounts and Contacts. We utilized the YEAR(), TODAY() and MONTH() functions in the Date validation rules along with the operators. In the Date/Time validation, the DATETIMEVALUE(), TIMEVALUE(), DATEVALUE(), and TODAY() functions are utilized in the validation rules. After going through this guide, you will know how to prevent the irrelevant/unwanted Date and Date/Time data before entering into the Salesforce system.

View the full article