Last Updated on August 10, 2023 by Rakesh Gupta
Now let us see. You are a super admin. If so then, one of the arrows that every super admin should have, in his/her Quiver, is a strong grasp of Validation Rule!
Pause. Then, assess your skill sets and ask yourself – where am I on the scale of one to ten – ten being highly skilled? Want to be higher on the scale? Great! Welcome! For, this article is solely focused on uncovering hidden nuggets of Validation Rules!
Validation Rule is a great tool for every system administrator. However, there are many hidden facts about the Validation Rule that are not well known. For example, how can you use one Validation Rule, to manage many requirements, using Custom Metadata types?
Read this article and learn how you can design Enterprise level Validation Rules, that will not only make your life easier but, it will also comply with best practices.
In achieve and maintain data integrity within your system – especially when data is entered manually by a user – it is very important to impose constraints on the values being entered in the system. To enforce data quality, the system administrator can use the following option:
- Validation Rule
- Validate data using Apex Trigger
- Unique fields
- Picklist and dependent picklist fields
- Lookup Filters
- Record Types
- Salesforce Flow
Validation Rules allows a system administrator to define custom logic and error messages to ensure data integrity. A Validation Rule can contain a formula or expression that evaluates the data in one or more fields and returns a value of True or False. Validation Rules also include an error message that displays when the rule returns a value of True – indicating that inaccurate data is being entered. Remember, a Validation rule only fires when a record is created or edited.
Let’s understand the workings of Validation Rules by looking at few use cases.
Business Use Case I
Edward Backhouse is working as a System Administrator at Gurukul on Cloud (GoC). Edward received the following requirement from his manager – don’t allow anyone to delete an Opportunity which is associated with an Account.
A solution for the above business requirement: As discussed earlier in this article, a Validation Rule only fires when a record is created or edited. But, we want to validate the data before deleting a record. To achieve this, we need to write a Before Trigger – similar to the code below:
trigger CheckAccountStatusBeforeDeletion on Opportunity (before delete) {
for(Opportunity myOpps : Trigger.old) {
if(myOpps.AccountId!=null) {
myOpps.addError('You are not allowed to delete Opportunity for active Account');
}
}
}
Now you understand how to handle data validation before a record gets deleted. Before moving ahead, remind yourself again that Validation Rules only fire when a record is created or edited. Secondly, that Validation Rule will not fire/execute when a record is updated through Workflow Rule or Process Builder’s scheduled action.
Edward Backhouse is working as a System Administrator at Gurukul on Cloud (GoC). Impressed by his Validation Rule skills, Edward received another requirement from his manager – (1) whenever a lead is created or edited it must have Email or Phone Number populated; and (2) bypass this Validation Rule for the system administrator.
It is easy to bypass a Validation Rule for a single user or a profile – in this case, a system administrator – by adding a condition in your Validation Rule as shown in the following screenshot:
Business Use Case II
So far so good. But, what happens if the manager comes back, like he always does!, after few weeks, and requests Edward to bypass Validation Rule for one more profile and one more user (belonging to a different profile)?
If this happens, it would create a headache for Edward – how many times is he going to modify a validation rule to bypass it for different profiles or users? As if this was not bad enough, let us suppose that after few months again, Edward gets yet another requirement to bypass the Validation Rule for few more users who belong to different profiles – What a nightmare!
A solution for the above business requirement: Let us bypass this scary scenario itself! And, let us learn how to use custom permission with Validation Rule.
Creating a Custom Permission
By using custom permissions, you can grant users access to custom apps. In Salesforce, you can use custom permissions to check which users can access a certain functionality. Custom permissions let you define access checks that can be assigned to users via permission sets or profiles – similar to how you assign user permissions and other access settings. You can even use custom permission to bypass validation rule for certain users or profiles. Let us create a custom permission to bypass processes. Perform the following steps to create a custom permission:
- Navigate to Setup (Gear Icon) | Setup | PLATFORM TOOLS | Custom Code | Custom Permission and click on the New button. Create a new custom permission, as shown in the following screenshot:
- To assign a custom permission to a profile (you can also assign it to Permission Set), navigate to Setup (Gear Icon) | Setup | Users | Profiles and open the System Administrator profile.
- Then, navigate to Apps | Custom Permission and click on the Edit button.
- Now, assign the Bypass Validation Rule custom permission to the profile, as shown in the following screenshot:
- Once you are done, click on the Save button.
Now we will modify the Validation Rule to check custom permission instead of checking profile in the preceding validation rule.
Click here to view the above video/Gif in full screen.
From now onwards, if a Lead gets created without Phone or Email, and the logged-In user doesn’t have custom permission assigned, then he will encounter Validation Rule error message. If you want to bypass a process for a single user, then consider using a permission set instead of using the profile for assigning Custom Permission.
Best practice Tips:- The above approach is very helpful when you want to onetime bulk upload data and the data is not cleaned. I have seen many administrators who deactivate Validation Rules and Processes, just to upload the bulk data. Now that you are a Validation Rule Ninja, go ahead and update your Validation Rules and Processes today to check custom permission – it will make your life easier.
While manually entering data, everyone likes the Clone record feature of Salesforce. Using it, one can increase the data entering speed. Sales reps especially like this feature because they have to enter the bunch of data quickly.
However, Caution on cloning an Opportunity! For instance, when you clone an opportunity record, by definition, Salesforce will create an opportunity record with the same information as the existing opportunity record.
As a result, if a sales rep is not careful, s/he can inadvertently clone a closed-won opportunity! As a best practice, before cloning an opportunity, a careful sales reps would/should check/update Opportunity stage. However, we all know that human errors are abound – sales rep are always on the go and try to squeeze in as many tasks in as little time as possible. If they are cloning an Opportunity and do not realize that they are cloning a closed-won Opportunity then – boom – the cloning will create a new opportunity with the closed-won stage! If so then, how can a System Administrator make sure that such an error does not occur?
Business Use Case III
Edward Backhouse is working as a System Administrator at Gurukul on Cloud (GoC). He received following requirement from his manager – when sales reps clone an opportunity with stage closed-won then, the system should display an error message to remind the sales rep to change the stage to anything other than closed-won.
A solution for the above business requirement: To solve the above requirement we will use ISCLONE() formula. The formula will checks if the record is being cloned. The formula will return TRUE if the record is being cloned. Otherwise, the formula will return FALSE. One can use the aforementioned formula to write a Validation Rule as shown in the following screenshot:
Best practice Tips:- When writing a Validation Rule make sure that you add proper spacing and lines in between formula or attributes so that it can be easily read by other administrators or developers. Secondly, write a meaningful message, so that users can easily understand it.
After Summer’18 release you can refer Metadata Types Records in Validation Rules. What does it mean and how can you benefit from it? Let us find out!
Custom Metadata Type is similar to a custom object – it allows application developers to create custom sets of data, as well as to create and associate custom data with an organization. All custom metadata type data is available in the application cache. As a result, it allows efficient access to the data without the cost of repeated queries (SOQL) to a database.
Custom Metadata Type is mainly used to store information that can be frequently accessed using Apex code. Custom Metadata Type performs better than a custom object because it is available in cache; and therefore, it does not have to be queried. The other difference, which you will notice between the custom metadata type and a custom object, is the difference in the suffix. Custom Metadata type has __mdt suffix at the end of the custom metadata type, as opposed to the usual __c for custom objects. Let’s take a look at an example.
Business Use Case IV
Edward Backhouse is working as a System Administrator at Gurukul on Cloud (GoC). GoC is in a business of selling electronic goods. Edward received the following requirement from his manager – whenever the total price of a quote is greater than $100K, Sales reps are not allowed to charge Shipping and Handling to the customer.
A solution for the above business requirement: The above requirement looks very simple to you and one can write a Validation Rules, as shown in the following screenshot:
Updated Business Use Case: Edward has few other Validation Rules where he is referencing the threshold amount of $100K to check other logic. As long as the threshold amount stays constant, Edward does not have to worry. But in Edward’s case, the threshold amount is decided by the upper management at the start of each financial year and, therefore, it can vary from year to year. This means that, if Edward uses the validation rule shown above then, every year he has to modify all the Validation Rules to reflect the new threshold amount! Nothing short of a nightmare for system administrator!
To avoid such nightmares, Edward is going to leverage the custom metadata type feature! With custom metadata type records available for reference in validation rules, Edward does not need to hardcode values. Edward will reference the records directly within the validation rules to avoid adding the same values to each rule.
To solve the preceding business requirement, we will create – (1) custom metadata type to store the threshold amount; use (2) update the Validation rule to refer custom metadata type record. Perform the following steps to solve the preceding business requirement:
- To create a new custom metadata type, navigate to Setup (Gear Icon) | Setup | PLATFORM TOOLS | Custom Code | Custom Metadata Types and click on the New Custom Metadata Type button. Refer the following video for step-by-step instructions: – Click here to view the video/Gif in full screen.
- The next step is to update the validation Rule to reference the custom metadata type record, as shown in the following Video/Gif: – Click here to view the video/Gif in full screen.
Best practice Tips:- Whenever possible try to avoid hard-coded values, IDs in Validation Rules.
Wasn’t that a great journey? Now you know how to write a Validation Rule that follow Salesforce best practices.
Yes, go ahead! Show off your newly acquired skills to your friends, colleagues, and families!
Please feel free to add constructive comments, insights – and yes, challenges too! – to the blog. Good Luck in your Journey towards becoming a Salesforce Ninja!
Technical Editor and Proofreader: - Munira Majmundar
2 thoughts on “Uncover Hidden Nuggets of Validation Rule – prized arrows in Admin’s Quiver!”