Val·i·da·tion

/ˌvaləˈdāSH(ə)n/, noun, the action of checking or proving the validity or accuracy of something.

Validation can also mean “recognition or affirmation that a person or their feelings or opinions are valid or worthwhile,” but we’re not here to talk about needy peeps.

I want to talk about Validation in Salesforce! They’re called Validation Rules.

Validation rules verify that the data a user enters in a record meets the standards you specify before the user can save the record. 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 display an error message to the user when the Condition is “False”.

Wow, that explanation is so techy. Here’s a visual explanation. If your computer is Jimmy Fallon and you (Jake Gyllenhaal) entered information that is wrong. Jimmy will let you know…

In The Giving Tree Foundation project that Abby and I created for Talent Stacker, we built a donation management app. To make sure that the Users were entering valid information into Salesforce, we created several Validation Rules on Donor (Contact) records. VR’s apply to fields within an object and it can be applied all the time or based on a condition. Our app doesn’t physically hurt our Users, but it makes sure that information is correct and will let our User’s know by not allowing them to save the record and giving an explanation through an error message. Here’s a list of all our VR’s.

A big requirement from the Client was that a Donation Manager could check the At-Risk field, but only a Program Manager [and Sys Admin] could uncheck the At-Risk field. To learn more about the process and how we completely automated it, you can read my Spreading Holiday Cheer post. But even though we automated it, the Donation Manager and Program Manager could respectively check / uncheck the At-Risk field. This VR ensures that only the PM can uncheck the field, by entering a formula. If the field was checked and is being changed to unchecked AND someone other than a PM [or Sys Admin] tries to uncheck the field, then the answer is TRUE and the record can be saved. But if the User was a Donation Manager, then the answer would be FALSE and the action would fail, the record would not save, and the User would get an error message that gently tells them that they are not allowed.

Another At-Risk requirement was that when the At-Risk field is checked, information is required to be entered into the At-Risk Reason field. So if both conditions are met, the answer will be FALSE and the User is sent an error message because the At-Risk Reason field cannot be blank. If the At-Risk Reason has a value, then it will pass the VR and the record can be saved.

Another requirement we solved with a VR was that a Donor Level could not be specified if the donor had not yet made any donations. You want to construct the formula to answer TRUE or FALSE. In this formula you have 2 conditions and both of these condition have to be met for the answer to be TRUE so the record can be saved. But if either of the 2 conditions are FALSE, then the answer is FALSE and the record can not be saved. So if either Total Household Gift = $0 OR the Donor Level has a value of “Major, Secondary, or Small” then the answer is FALSE and the User will get an error message. In the example below, I created a new donor that had no donations. When I tried to update the Donor Level to Major Donor, the system did not allow me to save the record and I got this error message.

The last VR we created was to make sure that a Preferred Phone / Preferred Email was entered on the donor record because we want our Users to know what is the best way to reach our donors. We don’t want them wasting their time calling all the numbers and possibly pissing off our donor.

As you can see though, there are 4 fields to capture a donor’s Phone # and 3 email fields. So if the User selects “Home Phone” as the Preferred Phone, then we better make sure that the User enters in a Home Phone #. Once I enter in a # in any of the 4 phone fields, the Preferred Phone field becomes required.

I’ll still get the same error message if all 4 phone fields are filled in. NOTICE THAT THE “PHONE” FIELD IS BLANK? What the what — why?

Bam! As soon as the User specifies the Preferred Phone (eg Home), the Phone field auto populates with the telephone # entered in the Home Phone field! That auto feature is out of the box in NSPS. I didn’t build it, but that was cool.

Take a look at these VR’s that made this work. Stop — don’t save the record if either of these 2 conditions are TRUE: Preferred Phone is blank or any of the 4 phone fields have a value with length >0. If any of the 4 phone fields have a value with length > 0, then Preferred Phone can’t be blank. Got it? Good.

Now, we also made a VR to make sure the Preferred Phone the User selected has a telephone # entered. If a User enters “Home” as the Preferred Phone, but there is no # in the Home Phone, the User will get this error message.

And this is how we did it. If you select a Preferred Phone [picklist values Home, Work, Mobile or Other], then the respective field can’t be blank. If it is blank, then the error message will appear and the record will not save.

The same VRs were created for email. The Preferred Email must be selected.

And an email must be entered into the field of the Preferred Email that was selected.

So that’s what Validation Rules are all about. Defining conditions so the system makes sure the User is being accurate. Another way to use VR’s is to ensure Users use the correct format, like email addresses, dates, etc. I’ll post about those later.

I pray you learned something about Validation Rules.

Now let’s get to the good stuff. Jake! Click on the link to watch the video! It’s hilarious!

Mahalo,

Lizette