May 5, 2017

Keep Clean Validation Rules with Custom Settings

Keep Clean Validation Rules with Custom Settings

Let’s talk about managing Validation Rules.How many of you have or have had Validation rules in your org that looks like this:

  $Profile.Name != "System Adminstrator",
  $Profile.Id != "00eo0000000KXdC",
  $User.Id != "005o00000040J3f")

Well doesn’t that look lovely.  Anyone else see red flags here?

  1. First off, Administrator is misspelled. (rookie mistake)
  2. What profile IS that? (I hate Ids sometimes)
  3. Who is that user that doesn’t have to follow validation rules? (Are they even Active?)
  4. All of this is done on a per rule basis, eww! That mean you need to check each one to see who can do what, yuck!

My personal validation rule number 1 is:

Do not over complicate rules

Followed closely by rule number 2:

Validation rule exclusions and bypass rights should not include Ids.

That’s right, I said they shouldn’t include Ids, and based on my example, they shouldn’t include names either.  If you made that assumption, you have assumed correctly.  I use a hierarchy Custom Setting to grant bypass rights to Validation Rules all in one place, with a single line added to each rule, easy peasy.  Here is how we do it.

What are Custom Settings

First off what is a custom setting?  A custom setting is similar t a custom object, it has custom fields that hold data that is accessible in your org. The data in Custom Settings is cached, meaning it does not have to use SOQL queries that count against governor limits.

List: A custom setting that provides a reusable set of static data, accessed across your organization. That means it’s like a custom object. You have a series of records with fields It’s just data in list.  It does not vary with profile or user, and there aren’t security settings so it is available organization-wide.

Hierarchy: A custom setting that uses a built-in hierarchical logic that lets you “personalize” settings for specific profiles or users.  What it does is it checks the organization level then the profile then the user.  The lowest value is returned, so if you have a user level record, then that user’s value is returned but if there isn’t a value for the user but there is for their profile then, the profile value is used, otherwise it defaults to the organization level.  

Only Hierarchy Custom Settings are available in Workflow Rules and Validation Rules, so that’s what we will use today.

Configure Your Setting

  1. To access custom settings, you go to Setup – Develop – Custom Settings.  Don’t let the fact that they are in the develop section scare you, this is configuration you got this.  
  2. We are working with a Hierarchy Custom Setting here, and you want to make sure to add a Description.


  • For each Validation Rule you need to grant bypass rights to, you will need to create a checkbox field. From the Custom Setting select New in the Custom Fields section


  • Select Checkbox as the field type and next


  • Personally, I like to add a link to the Validation Rule in the Description and Help Text to make my life easier. i also explain what rights are granted when checked in the Help text  The default value is Unchecked.
  • To use the field in a validation rule, access the Validation Rule you want to grant bypass rights to.
  • Click Edit and above the formula box click “Insert Field”


  • Find your Validation Rule custom setting it will start with $Setup.VRS__c (or whatever name you used).
  • Then select your field for the checkbox created to bypass this specific rule on the right.
 $Setup.meighanrocks__VRS__c.meighanrocks__O_001_Edit_Closed_Opps__c = False)

And that’s it! You can now check that checkbox to grant bypass rights to everyone assigned the profiles you select or the specific users you select in the custom setting with one little line.  How clean is that?


  • Once you have your fields created for the Validation Rules you want to override, you can access the ability to configure your settings by clicking “Manage”


  • The Manage button will bring you to the actual settings for your Custom Setting.
  • The top of the screen displays your default org settings, click edit and then save with all the checkboxes unchecked if you’d like the check it out.  Since checked means the user can bypass the rule, we don’t want any of these checked by default.


  • Below the Org Defaults are the Settings you will configure to bypass the Validation Rules.
  • Now, there are 3 levels to Hierarchy Custom Settings, the Org Level, the Profile Level, then User Level.  The Bypass rights are based on the lowest level for that user, so…
  • I will have the ability to bypass the rule and edit Closed Opps with the Sys Admin profile if the Profile has Edit Closed Opps access, and I do not have any lower level, User Level, permissions in this setting.   
  • Since I have user specific bypass access in the image below, but my user does NOT have Edit closed Opps, I will not be able to bypass the Edit Closed Opps Validation Rule.  The lowest level setting is used.


  • But here I granted the Meighan Brodkey User Edit Closed Opps access and now I do have bypass rights on Closed Opportunities


Check out the deck and video where I present how to use the Validation Rule Custom Setting in this post on the Admin Royal Rumble @ Apttus Accelerate 2017.

6 Comments on “Keep Clean Validation Rules with Custom Settings

May 5, 2017 at 12:21 pm

Aren’t “Custom Permissions” meant for this already?

Meighan Brodkey
May 7, 2017 at 5:24 pm

Great question! So yes, Custom Permissions can be used in Validation Rules to grant bypass access to specific profiles and/or permissions sets.

Disadvantages to Custom Permissions

  1. I find the required additional metadata a downside. A Custom Permission is assigned to users via Profiles and/or Permission Sets meaning you need to have the custom permission and if you want to assign it to a user, you need to do so on the profile level or create a permission set to do so. With the Hierarchy Custom Setting, you just need the Custom Setting, then you can assign to existing profiles or one off users.
  2. Also, you can’t see all those with bypass rights all in one place with custom permissions, just the list of custom permissions, not all the profiles/users assigned to each. As seen here.
  3. Finally, there is the apex side, Custom Settings are cached and accessible via system methods, so it do not count against your SOQL queries, Custom Permissions need to be queried via SOQL with the SetupEntityAccess and CustomPermission sObjects, that’s 2 queries. Check out Andy Fawcett’s idea for Native Apex support for Custom Permissions here
  4. Also the load time, Johan Yu has also tested the use of Custom Permissions by loading 1,000 Leads and observed a 70% increase in the time taken to load the data, read more here.

[…] is a Custom Setting?  We talked about Hierarchy Custom Settings in the Keep Clean Validation Rules with Custom Settings post, which let you set a default field value for the organization, then you can assign a value to […]

chris uttley
November 27, 2017 at 8:02 am

Can a custom setting value be changed in a FLOW?
I have a slightly different requirement than what you outline above. I want a validation rule to always run when someone is using the UI, but I want to turn it off when running a specific FLOW.
So is a custom setting a good solution for this?
If I create a custom setting with a checkbox field, and have it have a default value of FALSE< can in the FLOW the setting to TRUE while the flow is executing, then return it to FALSE when the FLOW is finishing up.
Is that possible?

Meighan Brodkey
December 22, 2017 at 1:19 am

You can change custom setting values with a flow. If you want to discuss, message me on Twitter (@MeighanSF) or on Hangouts ( and I’m happy to review any questions you have with you.


[…] is a Custom Setting?  We talked about Hierarchy Custom Settings in the Keep Clean Validation Rules with Custom Settings post, which let you set a default field value for the organization, then you can assign a value to […]


Leave a Reply

%d bloggers like this: