Validation Rule Settings - Bypass Validation Rules with a Hierarchy Custom Setting

Keep Clean Validation Rules with Custom Settings

Let’s talk about managing Validation Rules….

How many of you have or have had a rule in your org that looks like this:

AND(
PRIORVALUE( IsClosed ) = TRUE,
 OR(
  $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 Validation Rule bypass rights 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 so you don’t have to use SOQL queries that count against your governor limits.

List: A type of custom setting that provides a reusable set of static data that can be 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 type of 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.

_Meighan_Rocks__Custom_Setting_Definition_Edit___Salesforce_-_Developer_Edition

  • 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

_Meighan_Rocks__Custom_Setting_Definition___Salesforce_-_Developer_Edition

  • Select Checkbox as the field type and next

_Meighan_Rocks__Validation_Rule_Settings__New_Custom_Field___Salesforce_-_Developer_Edition

  • Personally, I like to add a link to the Validation Rule in the Description and Help Text to make my life easier, and in the Help text i also explain what rights are granted when checked.  The default value is Unchecked.
    _Meighan_Rocks__Edit_Validation_Rule_Settings_Custom_Field__O-001__Edit_Closed_Opps___Salesforce_-_Developer_Edition
  • 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”

_Meighan_Rocks__Opportunity_Validation_Rule___Salesforce_-_Developer_Edition.pngFind

  • 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.
AND(
 PRIORVALUE( IsClosed ) = TRUE,
 $Setup.meighanrocks__VRS__c.meighanrocks__O_001_Edit_Closed_Opps__c = False)

And that’s it, now everyone assigned the profiles you select or the specific users you select in the custom setting with that checkbox checked with have bypass rights with one little line.  How clean is that?

Management

  • 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”

_Meighan_Rocks__Custom_Setting_Definition___Salesforce_-_Developer_Edition

  • 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.

_Meighan_Rocks__Custom_Setting_Validation_Rule_Settings___Salesforce_-_Developer_Edition.png

  • 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…
  • If I am assigned the Sys Admin profile and the Profile has Edit Closed Opps access, and I do not have any lower level, User Level, permissions in this setting, then I will have the ability to bypass the rule and edit Closed Opps.  
  • 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 of settings is used.

_Meighan_Rocks__Custom_Setting_Validation_Rule_Settings___Salesforce_-_Developer_Edition.png

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

_Meighan_Rocks__Custom_Setting_Validation_Rule_Settings___Salesforce_-_Developer_Edition.png

Advertisements

2 thoughts on “Keep Clean Validation Rules with Custom Settings

    • Meighan Brodkey says:

      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 https://twitter.com/simplysfdc 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.

      Like

What are your thoughts? Seriously, comment.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s