Since launching my website back in May 2014, my 8 Essential Service Cloud Workflows post has been one of my most successful. I’ve received a lot of positive feedback from readers of which I’m very grateful for! My logic behind creating this post was to give ideas to people about workflows they can and in some cases, should create. It was also to spark off ideas with readers of the capabilities of Workflows and the Service Cloud.
I thought it would be a good idea to create a similar post for the Sales Cloud. This post is going to include a bunch of different Validation Rules that I have used in different implementations. Obviously these are not going to be suited to all readers Org’s but hopefully this will spark off ideas with people about how validation rules can be used with the Sales Cloud.
If you use Sales Cloud, it is essential you use some form of validation on your Accounts, Opportunities and possibly Contacts. Fresh installations without any validation can become messy quickly, especially when it comes to reporting. If you wish to run a report of say, your current customers by state or country, this is only going to be accurate if the Billing Country field is filled in every time. Luckily, this is very easy to enforce with Validation Rules. Here are a few examples that will help you get a hold of your data integrity.
1. Basic Account Validation Rules
When thinking about basic validation rules to add onto an Object, you need to think about what information can a sales rep derive from customer details. Enforcing fields like Annual Revenue probably isn’t the best idea seeing as your employees are going to find that hard to derive from just looking at a website or business card. Generally fields like Billing Country, Account Type and Possibly Industry contain data that can be derived fairly easily from a Company name and common sense. Here is an example Validation rule that makes sure a record is blocked from being saved if the Billing Country and Account Type are not filled in. The || (Or) parameter is used to make sure if Billing Country or Type is not filled in its blocked. The TEXT function is also used to convert the picklist value to text.
ISBLANK( BillingCountry ) || ISBLANK (TEXT (Type))
2. Dynamic Account Validation Rules
Taking these basic Account validation rules a step further we can create multiple dynamic validation rules based around a specific field. Lets say you need different information filled in depending on what the Account Type is. If they are a prospect, we probably need less information filled in than if they were a customer. For example if they were a customer we probably need information like a full Billing address but not if they were a prospect.
So something like this would work for enforcing fields for Account Type Customer
Text(Type) = “Customer” && ( ISBLANK( BillingStreet ) || ISBLANK( BillingCountry ))*
We can change this as needed to create more validation rules based on different Types
Text(Type) = “Prospect” && ( ISBLANK( Industry ) || ISBLANK( Website ))
*There is one problem with this validation rule which I will explain below
3. Country Validation Rules
In my opinion one of the most important validation rules you can implement on the Account is some sort of Validation on the Billing Country field. I don’t mean like my example above as there is a big fundamental issue doing it this way, and its human! Spelling mistakes, different formats and other ways of entering one country name can become troublesome if you let employees enter freely a country. Take the United States of America for example, USA, U.S.A, US, United States, there are many different ways to enter one country name and when it comes to reporting, this isn’t going to bode well.
Address Tools Free
There are a few ways to solve this problem and even Salesforce has a tool which is in Beta. The first of these is an App from the AppExchange which is really simple and instantly solves this problem. It’s called AddressTools Free V4 and it gives you a finite amount of countries and states to choose from when you type starting in a country. This instantly solves the problem and is an extremely effective free App. Check out the video below for an overview.
Custom Validation Rule
There is a second way to solve this issue which has been preferred in a few implementations I have dealt with. You can create your own validation rule to handle countries. There are a couple of ways you might wish to use this over an App, you have complete control over what the validation rule does and you may not want to enter the country format as a full name. What I mean by that is you may want to use the ISO 2 letter code, GB, US, CA, NZ ect. To do this you can simply create a very basic CONTAINS function validation rule and complete all the countries you wish to use. Something like the below.