Validation rules can be a powerful tool to help maintain data integrity in systems. They’re custom logic tests you define so data has to meet certain standards or format before being saved. The test is run and returns either true (there is an error, do not save the record) or false (validation succeeded, carry on). In the case of an error, a message will display on the screen, the user can correct said error. Happy days.

Sounds great – who wouldn’t want that everywhere?!

Not so fast. When used wisely, validation rules are a great ally, but can equally become the stuff of nightmares when they’re not implemented appropriately or overused.  A common pitfall of adding validation rules to an existing system is that it can prevent existing records from being saved when reopened by an unsuspecting user who is challenged to provide a value for a field for which they are not responsible for or have no knowledge of. Imagine that pickle for a thousand records.

These “hidden figures” work in the background (users never see them) and they are also run before any other automation rules are processed. That’s good news for an administrator because they get a first say on what is not valid upon record-save, but we must consider all the automation processes which exist downstream, particularly when adding a new validation rule to an established system.  These rules are run underneath the UI, the API, any AppExchange add-on or custom code, even Visualforce pages, which means that changes in validation could prevent existing processes or integrations from working as originally designed.

More validation rules don’t necessarily make for a better Salesforce system. Validation rules primarily help to protect data integrity, requiring that a value that is critical to system operation is provided in the correct format. If you want to improve data quality, there are a few different tools you can try before turning to validation rules. So ask yourself a few questions first:

• If you want every new Contact record created by your salesperson to have the phone number entered, you don’t need to create a validation rule for that.  Is it the case where you can simply mark a field as required on the page layout?

Use different page layouts to make different requirements for certain profiles or mark a field as universally required for all users.

• Can you create picklist values and dependent picklists (and perhaps mark those fields as required as well) to narrow down value possibilities? If you want to avoid typos or duplicates, create picklist values for a State field, for instance.
• Can you use lookup filters instead? They can give you similar results if you want to limit the number of available options.

Having said that, there are cases where validation rules are the best tool for the job. The good news is that in Salesforce, administrators create them declaratively (point-and-click). But you need to to write formulas that follow a Boolean logic (bad news if writing formulas is not your thing).

Writing formulas from scratch can be intimidating for some but the formula wizard in Salesforce will help you check for syntax errors (you can also read this handy tutorial here). I strongly suggest you test any formula on a Developer Org or in a Sandbox environment before deploying it.

There are plenty of resources online (you can find the links at the end of this post) that can help you craft a formula specific to your case. Most of the time, you can find a pre-made expression for a similar scenario where it can easily be tweaked to fit your needs. Be careful though, because even official documentation can contain formula errors.

So always test your formulas in a safe environment first!

A Few Handy Formula Functions for Validation Rules:

Use:  NOT (ISBLANK)

When: Blank entries are accepted as a possible value. E.g. Account Number must be numeric if not blank.

Use: REGEX

When:  A field value must have a specific format.  E.g. Email field must contain a valid email address format.

When there is a predictable pattern of numbers, letters and punctuation, REGEX is your friend.

REGEX stands for Regular Expression and is used when you want the value to follow a specific format. Social Security Number is a classic example but you can use as a rule for Driver’s License numbers that have letters and numbers together, postal codes etc.

Use: REGEX and LEN together in the same expression to specify the format and length of the value to be entered. (Alternatively, you can set the specific length of a custom field in the field options)

Tip: You can download a list of US Zip Codes in CSV format here.

Use:  ISNEW

When: The rule should only apply on record creation

or

Use: ISCHANGED

When: the rule should apply when a field changes.

Did You Know?

You can include the RecordType.Id merge field in your formula

When: You need to apply different validations for different record types.

• If your org has multiple page layouts for the object on which you create a validation rule, check that the rule works as intended on each layout.

New in Spring ’17:

Include IsPersonAccount to a criteria

When: You want to ignore Person Accounts from the Name field in Account-related rules.

Previously, Account-related processes that used the Name field only evaluated Business Account records, but as of Spring ’17, Person Accounts are automatically factored in. Source

• When you want one or more fields to be conditionally required depending on the value of another field. E.g., when Opportunity Stage is Closed/Lost a validation rule can enforce that the field “Loss reasons” has a meaningful value.
• If you want a discount percentage to have different limits for different roles or users, a validation rule referring to Profile.Name, User.Id or UserRole.Name may be your solution. Sample User Role and Profile Validation Rules

Keep in Mind:

• Validation Rules don’t apply if you create new records for an object with Quick Create.
• If your organization has any integrations that use this object, verify that the validation rule functions as intended for each integration.
• Validation rules run even if the field referred in the formula is not on a page layout.

Finally, before deploying a new validation rule, make a plan for how to update existing records. E.g. Run a report to find potential errors, can you use Data Loader to insert new values that observe the new criteria or will you have users enter them manually?

Do you have a favorite validation rule formula or tip? Share with us in the comments!

Other Helpful Links:

• Validation Rules Considerations
• Examples of Validation Rules
• Sample Opportunity Management Validation Rules
• Sample cross object validation rules
• Miscellaneous Sample Validation Rules
• REGEX Cheat Sheet
• Regulazy (a Regular Expression builder tool – genius!)