Validation Rules

What is a validation rule?

A validation rule will conditionally prevent records from being saved.

Why use validation rules?

Use validation rules to ensure that users enter valid data when creating or updating records.

Open Example

When an opportunity stage is “Closed/Lost”, the rep must enter the field “Reason Lost”:

1-29-2013 4-06-14 PM

Note, “Reason Lost” is NOT required when the opportunity stage is any other value.  Therefore, making “Reason Lost” required on the page layout would not be appropriate.  The key benefit of validation rules is that they conditionally prevent records from being saved.

For more examples:
Examples of Validation Rules
[Should / Long / Salesforce.com]

Creating validation rules

Validation rules can be created on most standard and custom objects, and use the same syntax as formulas.

Open Example

To create the “Reason Lost” validation rule, I navigated to Setup –> Customize –> Opportunities –> Validation Rules.

1-29-2013 4-34-20 PM

And created the following rule:

1-29-2013 4-35-55 PM

This rule will only trigger when the stage name is “Closed Lost” and the field “Reason Lost” is not populated.

Considerations

  • Validation rules will impact API usage, web-to-lead, and web-to-case submissions.  Make sure to structure your validation rules so that they will not unintentionally interfere with these operations (such as rejecting a web-to-lead submission).  It is possible to either add exceptions for users/profiles in the validation rule, or use custom settings in conjunction with validation rules (this second solution is likely more complex than what would be presented on the ADM201 exam).  In some scenarios, you may need to disable validation rules when importing or updating data, and reinstate them afterwards.
  • Too many validation rules can be frustrating from a user interface perspective, as the error is not presented until after the user attempts to save the record.  Make fields required when possible (as they are indicated as required in the user interface), and employ other usability features as appropriate (for instance, create a page layout section for information required when an opportunity is lost if more than 1 field is captured).
  • Some formula arguments (such as VLOOKUP) can only be used in validation rules.

27 Responses to “Validation Rules”

  1. siddharth1101 September 12, 2016 at 6:46 am #

    Hi john,

    I have a validation rule that “rate” cannot be lower than $25, now I want anyone with a director or above hierarchy to be able to insert ANY rate. How would I accomplish this? Thanks, Sid.

    • JohnCoppedge September 14, 2016 at 12:44 am #

      Have your validation rule evaluate the $user global variable (e.g. look at the user profile). You’d also need to check that the value in that field has changed (priorvalue not equal to current value).

      Should look something like this (not exact syntax):

      $User.profile <> ‘profile allowed’ &&
      Amount > 25 &&
      PRIORVALUE(Amount) <> Amount

  2. j_cap23 September 5, 2016 at 5:23 pm #

    I am trying to create a validation rule that doesn’t allow a value greater than the current value. My custom field is Tank__c, can anyone help me with the syntax? I tried ISCHANGED but run into errors after the “greater than or equal to” symbol….any help would be appreciated!

    • CarlosSiqueira September 5, 2016 at 6:19 pm #

      Can you try this?

      IF (Tank__c >PRIORVALUE(Tank__c),true, false)

      • JohnCoppedge September 5, 2016 at 6:35 pm #

        Yep, great suggestion Carlos

        • CarlosSiqueira September 5, 2016 at 6:41 pm #

          Thanks John.

          I know that works, but just don’t understand why/how…

          I know what is validating, just don’t understand the flow for true or false

          • JohnCoppedge September 5, 2016 at 6:52 pm #

            Taking a second look at this – you actually don’t need the IF statement.

            You can just put in:

            Tank__c > PRIORVALUE(Tank__c)

            The validation rule will fire if the result of the formula equates to true.

      • j_cap23 September 6, 2016 at 11:08 am #

        Spot on Carols, thanks. I was trying :
        PRIORVALUE(Tank__c) >= ABS(Tank__c)
        which requires a lesser tank value for ALL field updates on the record. Any explanation on how to narrow it down to a specific field rather than the entire record inputs? It’s apparently the IF operator. I never would have thought to use the true or false inputs on my own. All of this seems to make sense until I try the next field on my own : ) Thanks for the help.

        • j_cap23 September 6, 2016 at 11:13 am #

          AAAaaand I scrolled down to John’s reply. So if it wasn’t the IF operator, what made my formula apply to the entire record John?

  3. michaelpierce December 2, 2015 at 6:09 pm #

    John,

    If I want to write a validation rule to prevent duplicates, but not based on Name… is that possible with VLOOKUP? (From what I see and experiment with, VLOOKUP is only based on name.)

    SITUATION:
    Do not create a record of ContactID (lookup field to Contacts) + Interest (from picklist, e.g. “Physics”).

    *So the VLOOKUP needs to reference all the past ContactIDs AND Interest picklist values to prevent a duplicate combination.
    * I thought of adding a formula field to create a unique ID (= ContactID + Interest)… but I don’t think I can reference that with a VLOOKUP since it’s not the Name field.

    –Michael

    • michaelpierce December 2, 2015 at 6:12 pm #

      By the way — I love your site. It’s the most helpful thing I’ve found.
      Taking ADM 201 on 12/30 (to fulfill a goal to take it this year). 🙂

    • JohnCoppedge December 3, 2015 at 12:02 am #

      This article goes into a better explanation than I could easily: https://success.salesforce.com/answers?id=90630000000gyFzAAI

      It looks like you are correct that it works on the name field. If you were using a dedup function on contacts, you could use the data.com duplicate blocker also.

      • michaelpierce December 3, 2015 at 3:42 am #

        John,

        Thanks for your speedy reply. I did see that Success article (I actually attempted to figure it out before I messaged you).

        I appreciate your help.

        –Michael

        • JohnCoppedge December 3, 2015 at 3:14 pm #

          Sure!

          In your example you could also use a workflow to concatenate the contact id and interest and store that value in a text field marked as unique.

          You’re on the right track for vlookup but I’m not sure that it would work exactly the way that you want it to.

  4. Rena Bennett-Dellwo April 6, 2015 at 10:55 pm #

    In the first “Consideration” there’s a link for more information about using custom settings in conjunction with validation rules. In the target of this link, it says “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 [some odd characters] > New. ”

    What are Default Organization Level Values? And, where are they set and why? (I’ve looked through Help & Training for this, but no luck. They don’t seem to have anything with OWD, which is the closest I was able to guess or find.)

    • JohnCoppedge April 15, 2015 at 2:24 am #

      Here’s another link that may help: http://www.buanconsulting.com/the-custom-setting-every-administrator-needs/

      When you create a hierarchy based custom setting you need to set the default in order it to work correctly:

      “Set the organization default behavior by clicking the New button above the Default Organization Level Value; The values will default appropriately in this instance to show that the default behavior will be to run validation rules, so you can just save.
      Begin adding your exception profiles by clicking New”

      • Rena Bennett-Dellwo April 15, 2015 at 12:51 pm #

        Thanks, John. This actually a whole new can of worms because I had/have no idea what a custom setting is. Ack and yikes! That link talks about “a new Validation Rule Exception custom setting object”. Huh? For expediency’s sake, how likely is it that this topic will be on the cert exam?

        • JohnCoppedge April 15, 2015 at 5:16 pm #

          Not very likely 🙂 I will look at updating the materials here to reflect.

          • Rena Bennett-Dellwo April 15, 2015 at 5:27 pm #

            Thanks, and yay!!! 🙂

      • CarlosSiqueira June 20, 2016 at 10:19 pm #

        This is an awesome feature.

  5. Benjamin Schaefer December 18, 2014 at 3:18 pm #

    Goal – Execs are being transferred leads that are not followed up on as their day to day tasks do not include managing leads. I want to remove the ability for someone to transfer them a lead BUT keep the ability for them to view reports/dashboards components on leads.

    How could this be achieved? Is it possible to create a Validation Rule that prevents the transfer of a lead when the new Owner ID equals that of one of the execs or their associated profile?

    • Alex Messinger December 18, 2014 at 3:55 pm #

      how about this rule on the record owner (syntax is incorrect)

      and (priorvalue(record owner.profile)=minion, record owner(profile)=executive)

  6. Tasnim Tailor June 16, 2014 at 2:08 pm #

    I have two page layouts (two diff record types using it) with a field “Salary” present in only one of the layouts. If I create a validation rule say SALARY__c 0, it fires for the page layout where I have not included salary. How do I avoid this?

    • Tasnim Tailor June 16, 2014 at 2:09 pm #

      This is just an example, could be any kind of validation that I just want to fire with one page layout, how do I do that?

      • JohnCoppedge June 16, 2014 at 3:01 pm #

        You can’t based on page layout alone (as page layout is not a data element) – you would need to use record type (or some other field) within the validation rule.

Leave a Reply