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?
- First off Administrator is misspelled (rookie mistake)
- What profile IS that? (I hate Ids sometimes)
- Who is that user that doesn’t have to follow validation rules? (Are they even Active?)
- 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
- 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.
- 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, and in the Help text i also explain what rights are granted when checked. 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.
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?
- 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…
- 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.
- But here I granted the Meighan Brodkey User Edit Closed Opps access and now I do have bypass rights on Closed Opportunities