8 Quick Validation Rules – Cleaner Sales Cloud Data Guaranteed!

Share this article...

Data accuracy is key when you make decisions based on Salesforce data. There are a number of things you can do to ensure data is clean and relevant in your org, and validation rules are one of them. Enforcing some of these rules can help stop users from entering duplicate or wrong data, skipping a certain step or not filling the required information.

Before you start activating Validation Rules in your org, a very useful tip is to create a checkbox field (ex. OverpassVR__c) on the User object that you can check when you don’t want Validation Rules to apply to a specific user at a specific time. After that, you just need to enter the following condition in every Validation Rule you create in your org:


&& NOT(OverpassVR__c)

Of course, this is only for exceptional situations because validations should always apply to every user, including the System Administrator.

1. Required fields for Lead Conversion

Leads are unqualified prospects and when you first find them you usually have little information about them. You get to know more about them during the qualification process, i.e. checking that both seller and buyer have an interest in working with each other. Typically, once you have qualified a prospect, you convert the Lead into an Account if you are going to continue with the sales process. A validation rule is very useful at this point to ensure that the information required to continue negotiating with the qualified prospect is in Salesforce.

Validation Rule Example:




ISBLANK (Phone),

ISBLANK (Email),

ISPICKVAL (Rating, “”)


Additional Use: If you change ‘IsConverted’ for ‘IsWon’, you can use the same type of validation rule on the Opportunity object to ensure the fields required to close an Opportunity as won are filled.

2. An Account can only be created through Lead Conversion

If you don’t allow users to create Accounts, they won’t be able to convert Leads either. However, this is a little trick to discourage sales agents from skipping the Lead process and from directly creating Accounts in Salesforce (if this happens you are losing a lot of valuable information). Additionally, this validation will ensure you carry over the Lead created date to the Opportunity, so that you can calculate the total time it takes to close the first deal.

You will need to create a lead formula field that saves the value of the standard Lead date field. You will then need to map the lead formula field to a read-only date field you will have created in the Account.

The last step is creating the following Validation Rule for the Account object:

ISBLANK ( LeadCreatedDate__c )

3. Customer Contacts can only be related to Customer Accounts

If you are using record types in your org to separate different types of Accounts and Contacts (ex. providers and customers), this validation will help you not to get your Accounts mixed up, i.e. ensure that provider Contacts can only be related to provider Accounts and that customer Contacts can only be related to customer Accounts.

Validation Rule Example:

RecordType.Id = ‘01234000000kL1i’ &&

NOT(Account.RecordTypeId = ‘02345000000kL1d’)

Additional Use: If you are also using different Opportunity record types for each of your Account record types, you can use the same type of Validation on the Opportunity object to keep data consistent.

4. One Open Opportunity at a time

The relationship Account-Opportunity is designed for an account to have multiple Opportunities, if necessary. However, each Opportunity represents a sales process and you usually close a negotiation (whether successfully or not) before starting a new one. If that’s the case in your business, this Validation Rule can avoid there are duplicate Opportunities related to the same Account in your org.

The first step is creating a roll-up summary field on the Account to count the number of open Opportunities as you can see on the image below:

The second step is creating the following Validation Rule:

Account.NumberofOpenOpportunities__c > 1

5. Won Opportunities must have an Amount above 0

Whether users manually enter Opportunity Amounts in your Salesforce org or it is automatically calculated when users select Opportunity Products, this validation will prevent your pipeline data from getting messed up with blank or null Opportunity amounts entered by mistake:

Amount <= 0

6. Lost Opportunities must have a Lost Reason

Tracking lost sales opportunities can help you identify potential issues in your sales process. New sales techniques, price adjustments, or even product/service improvements could be needed. By analysing the most common reasons why the sales team is losing deals, the company can make the right decisions.

Before activating this Validation Rule, you will need to create a new Opportunity picklist field with a list of reasons why your sales could potentially get lost. There are surely many reasons, some that you might not even think of yet, but resist the temptation of using a Text field for it. Remember that for reporting you do not need to know the specific details why the sales negotiation failed.

Validation Rule Example:

ISPICKVAL (StageName, “Closed Lost”)


ISPICKVAL (LostReason__c ,””)

7. Contract Start Date must be prior to Contract End Date

This Validation is a must if you use Start and End Dates on the Contract object or you have created any pair of date fields to enter the start and the end of a period of time. It is obvious that the start date will refer to a given date way before the end date; however, who hasn’t ever picked the wrong month or year by mistake? This Validation will remind users when the end date has been filled with a date earlier than the start date.
Validation Rule Example:
StartDate > EndDate

8. Order Products cannot be modified if Orders are “Activated”

Once an Order has been placed, its related Products and their details do not need to be modified. Any incongruencies between real orders and Salesforce data could be disastrous for your business analytics, but a simple Validation Rule will keep such sensitive data safe.

Validation Rule Example:

ISPICKVAL (Order.Status, “Activated”)


Clean data is vital to make good business decisions and validation rules are there to ensure Salesforce users provide the right data. Do not worry about restricting your org: rules are better than messy data. Just make sure error messages are clear, so that users understand what they have to do and don’t get frustrated.

7 thoughts on “8 Quick Validation Rules – Cleaner Sales Cloud Data Guaranteed!

  1. Newer admins might not know and experienced admins might forget isn’t common knowledge: making any field required with conditions not tied to the page layout. “Field must not be blank unless role is Finance or Admin” is easier than creating a separate page layout.

    Also, contact info formatting like “if country equals “United States”, state can only be AK, AL…”

  2. Figured this out many years ago .. having a way to easily bypass Validation rules saves a lot of headaches, frustration and time. I have a ByPass VRs checkbox in users. Really important when you are making changes to old data that may predate newer VRs

  3. Just one more comment.
    I like to add comments to my VRs (and formulae) because sometimes I find it hard to remember what or why I did it.
    This syntax (below) works in Salesforce VRs and formulae – I use it a lot to help other System Admins understand what I’ve done
    /* Add comments */

  4. Great suggestions, though I would recommend against hard-coding record type IDs into the validation rule as you have in #3. Those things are subject to change (rarely but it happens) and will frequently differ between sandbox and production orgs. It is always recommended you use RecordType.Name == “TheName”

  5. John Sadler that’s good feedback. It’s also useful to put a general description of the rule or formula in the Description field. That may seem obvious, but in my experience hardly anyone makes use of that feature.

  6. For the most part this is a really useful article with great tips. However there are a couple of points to note.

    Tip#1: it would offer greater flexibility to add the flag to a hierarchical custom setting instead of the User record. The hierarchical custom setting an be referenced in the validation rule equally but can then be applied not just to Users but to entire profiles of users also. Much greater flexibility!

    Tip#3: Please do not hardcode record ids into any expression or code – including and most importantly record type ids and profile ids. When you migrate the record type up through environments the Id will change unless it already existed in production from which the sandbox you’re working in was created/refreshed. To avoid all of this entirely it is better to use the recordtype.name.

Add Comment