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
- Process Builder
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: 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: 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! Read the rest of this entry!