Validation Rules + Custom Settings = Happier Admins

Have you ever just thought “If only this validation rule were off.” or “I wish I had written this validation rule to not apply to admins.” If so, Custom Settings are about to be your best friend. Think of Custom Settings like a very customizable on/off switch. You can decide if and when you want the rules to apply. Imagine being able to choose to exclude a specific user or profile at will; and you don’t have to edit or deactivate any rules. That’s exactly what Custom Settings can do for you. Let’s take a look. 

Custom Settings 101

So what’s a Custom Setting? Technically, it’s a set of data that can be used hierarchically (to an org, profile, or user). It’s not really a custom object, but if you want to think of it like a custom object that is just for setup, that’s ok. Custom Settings can be used in formula fields, validation rules, processes, flows, apex, and the SOAP API. We are going to talk about validation rules, but if you’re wondering if you could use them to extend control to other tools; the answer is yes. 

Creating a Custom Setting is really easy. From Setup just do a quick search for Custom Settings (or for those of you that like clicking: Custom Code → Custom Settings). Click New. You’ll see there are only a few fields to fill out. I like to keep the Object Name short, because it’s part of what you’ll reference later on. Be sure to choose Hierarchy as the setting type and keep the visibility public and populate a description.

Now that we have our Custom Setting, we need to add some fields to it that we can use as our control. When I set this up, I generally create one field for each object that I want to create a bypass for. Each field will just be a boolean (checkbox) named after the object you want to control. These fields should default to TRUE or checked. You can create fields by clicking the new at the top of the custom field related list. In the example below, I’ve included a field each for some common objects. 

Before we finish, let’s review something we briefly touched on earlier. We’re working with a hierarchical Custom Setting. This means we can have the settings apply differently at the org, profile, or user levels. This is why Custom Settings are so great for our validation rules. The rules can be ‘on’ for everyone but us. Here’s how we make that happen. Click Manage. At the top you’ll be able to set an Org Wide Default. Set this up so that all of your fields are TRUE or Checked and click save. 

Now, from the related list at the bottom of the page, click new. Select either a specific user or profile, then set your values. I’ve created one for the System Administrator profile. 

It’s important to note here that the most granular setting you have is the one that will apply. In the example above, the whole org values will apply to everyone except System Administrators. Were I to create a policy for a specific user that was also an administrator, that would be the most granular and would apply. I’m going to edit the policy for System Administrator so that the Case field is set to FALSE or unchecked.

Bringing it all Together

We’ve got a Custom Setting, and a policy for System Administrators. So now what? Let’s take a look at a case Validation Rule. 

Check out the second line in the rule above. We use $Setup.VR__c.Case__c to make a reference to our Custom Setting. This isn’t saying anything specific about any user or profile. It’s just referencing the custom setting’s most granular policy that could apply to the user. 

If a non-System Admin user were to try saving a case with a Status of Working and no type, they would be blocked by the rule because the Org Default we set has VR__c.Case__c set to TRUE. If a system admin were to do the same, they would be allowed to save the record because VR__c.Case__c is set to FALSE for the System Administrator profile. 

This is the power of the custom setting. We can edit the rules within the custom setting with just a few clicks, and not have to worry about messing up our validation rules! Need to allow a user to load some old records? No worry. Just uncheck the right boxes and away they go. Once they’re done, check them and all’s right with the world, no extra risk involved. 

Final Thoughts

Good validation rules have a few notable traits that you can see in the example one above. Note that the error message has a “Debug code” that clearly ties the error message to the name of the validation rule. This makes life easy when the overly cropped screenshot with just the error message shows up in your inbox. There are some great articles by MVPs like Meighan Brodkey (such as this one) that show how to build on a rule-by-rule basis. This is also totally acceptable. It’s just a matter of how much control you want or need.

Hope you find this useful! See you in the next one! ✌

Thank you for being an awesome reader! Subscribe to this blog for receiving all the latest updates straight to your inbox. 🙂

NOTE: This post is written by Mike . Click here to know more about this trailblazer!