2

Exceptions to Validation and Workflow Rules [Best Practices]

Posted February 25th, 2012 in Tips & Tricks and tagged , by John Coppedge

I find it very helpful to provide a method to turn off/on validation and workflow rules on a per user or per profile basis.  Advantages:

  • Data migrations and manipulation.  I was loading contact data split into two files (1st for name, 2nd for contact details), while a validation rule prevents creating a contact without a phone or email address.
  • Integration.  Often times integration should not be subjected to the same rules as a typical user.  You could hard code the integration user details into each validation rule, but that isn’t very extensible.
  • Flexibility.  You’ve got it.

 

There are two basic ways to accomplish this:

1. Add exception fields to a custom setting.  There are some complexities with this method but it is my favorite (make sure to set org wide defaults!).

2. Add exception fields to the user record.

Here’s a brief overview of the pros/cons of each:

Custom Settings User Record
Per profile & per user. Per user only.
Must be manually migrated to new sandboxes (except for full sandboxes). Carries over on user record when sandbox created.
Workflow rule conditions must be written as “when formula evaluates to true”. Workflow rule conditions can be constructed as normal.

Here’s how to create a validation rule using custom settings:

  1. Create a new custom setting, type Hierarchy, visibility Protected (Develop –> Custom Settings).
    Screenshot - 2_25_2012 , 11_27_20 AM
  2. Create a new field (I prefer checkboxes) for a validation rule or set of rules.
    Screenshot - 2_25_2012 , 11_29_53 AM
  3. Notice that Default Organization Level Values are not set by default.  This must be set in order for the validation rule to work.  Click Manage –> New.
    Screenshot - 2_25_2012 , 11_32_15 AM
    Screenshot - 2_25_2012 , 11_34_17 AM
  4. Create your validation rule, referencing the custom setting:
    Screenshot - 2_25_2012 , 11_36_08 AM
  5. Now the validation rule is active:
    Screenshot - 2_25_2012 , 11_37_13 AM
  6. (Optional) Update your list view in your custom setting to include newly created field(s).
  7. Add exceptions in custom setting for users/profiles:
    Screenshot - 2_25_2012 , 11_40_24 AM
  8. Your validation rule is now inactive for system administrators.

 

Note that if you want to use custom settings in conjunction with a workflow rule, you will need to set the rule criteria to formula as shown below.  I can’t think of any scenario where this would prevent you from doing something that the standard criteria engine allows, but it can make writing the rules a bit more complex.

Screenshot - 2_25_2012 , 11_43_05 AM

Like stated above, be aware – custom settings do not carry over when sandboxes are created (with the exception of full sandboxes).  Make sure to build this in to your sandbox refresh strategy.

 

Another method is to use the user record.  I haven’t  written a step by step for that, but the process is very similar.  You need to create the checkboxes for exceptions on the user record, and then build those fields into your validation and workflow rules.

 

Have you implemented something similar?  Would love to hear about it!  Cheers,

 

John

2 Responses so far.

  1. Kyle PetersonNo Gravatar says:

    I’ve cringed doing things like hardcode userid’s and profiles into validation rules before. Will definitely give this a try, thanks!

  2. KristinNo Gravatar says:

    Thanks for the explanation on using custom settings to avoid hard-coding of profiles into rules. I’ll just add that with Summer ’13, custom settings are now copied to all sandboxes (not just Full Sandboxes).

Leave a Reply