Architecting for Success
There is a Russian proverb: “Doveryay, no proveryay.” It was made popular in America when President Raegan used it to describe the nations relationship with the Soviet Union: “trust but verify.”
The same holds true with many processes and systems that companies put in place. We want to empower our teams to do their jobs as efficiently as possible, while also making sure that our customers receive the highest quality service available.
There are 2 main reasons that many companies turn to validation. The first is to ensure data quality. The second is adherence to process. Validations can be extremely beneficial in helping to reduce the number of approvals that are needed and manual steps can be reduces with the insertion of common validation rules for data. There are two steps one should use in determining the type of validation that you need:
Step 1: Determine what you are validating. This step sounds easy but might prove to be more complex than originally thought.
Step 2: Explain why you want to validate that particular element or feature. As we mentioned in a previous article, you can do quite a bit of validation with the functionality and features most CRM tools and platforms already have available.
Good data quality begins with a good data model. Read that again, it is extremely important! I have run into situations at various organizatons and client environments where their struggles can be directly traced back to a poor, or even non-existent data model. There are certain field types that have special functionality on the platform such as Phone numbers, Geocodes, Emails, and Currency. Other fields have specific formats and uses. This article is not a discussion on data modeling, and since a list of the different field types and their uses and attributes can be found here, we’ll suffice to say that the first line of defense for validating your data for quality is to use the correct type of field.
One thing to be cautious of, is validating data in your CRM such as Salesforce for another application’s use. I recall one specific request to put a validation rule on a phone number field so a downstream application could use the information without having to filter or format it. Unbeknownst to the requestor, the format that they had asked for had the following impacts:
Phone number was to validate and format numbers in a 10-digit US phone number impact, which prevented both international numbers (accounting for 1% of the current records)
Prevented users from entering extension information into the phone field
External applications that were used to collect the information and submit it to Salesforce broke because of the new rule around formatting
In this type of situation, I normally recommend that you start with which system is requesting the data. If the data is being queried from one application by another the requesting application should be responsible for ensuring the format. If you are writing data to an external application from Salesforce, then Salesforce should format the data before sending it. You should avoid using validation rules on the data model for external applications unless it is an enterprise-wide validation for the data to avoid the issues raised above.
If the validation is needed to ensure that a process is followed, start by asking if all records need to follow the validation. You may find that there are hidden exceptions to the validation. This will help with determining the impact of the validation rule upfront before you hear about it from end users.
Another question that you need to ask is if all users need to follow the validation, or if there are specific users or groups of users that the validation should not apply to. If there are, I recommend using Custom Permissions instead of hard-coding profile names or ids. You can use Custom Permissions to both require or bypass a specific set of rules for key users.
The next thing to consider is if the validation requires data from other records. Is the data on a related record, or on a child record? If all the data that is required for the validation is on the same record, or on another record that is available through a Lookup or Master-Detail field, use a Salesforce Validation Rule for the validation.
Let us consider the following scenario. Acme, Inc has a requirement where the Opportunity cannot have a Pricebook assigned to it unless the Account’s Industry is set because of another requirement where Pricebooks can only be used if they match the Account’s Industry. There are a couple of ways that you could solution this. First, you can use the standard Salesforce validation rules for this if the field indicating which industry a Pricebook was available for is on the Pricebook. This is possible because both the Account and Pricebook are referenced by the Opportunity.
However, this solution does not allow for a Pricebook to be available for multiple industries. I have seen orgs attempt to use multi-select picklists to attempt to solve for similar requirements. Please, do not ever use multi-select picklists this way. Aside from being a bad practice in data modeling, this still does not solve for the requirement with a validation rule because multi-select picklists have specific functions that are available in formulas (and yes, validation rules use the same functions) and the includes function does not allow you to put in dynamic text at this time. The better solution for this would be to have a new object related to the Pricebook that indicates that it is available for specific Industries.
You should then do your validation with Apex in a trigger for both Before Insert and Before Update. This allows you to control the available industries as a data change in the future, making it much easier for the users that are managing the Pricebooks to maintain. If you have read the article on the Salesforce Automation Pyramid already you’re familiar with the philosophy “Why make it Configuration when it can be Data-driven?” This is an example of using code to make the solution data-driven for future use.
Is the data controlled by another record in Salesforce that is unrelated to the current record? There really is no way around this one. If you have a requirement for your validation that requires checking records or data that are not directly related to the current record (for example, not allowing a Case to be assigned to a Support user if they already have more than 15 open Cases) you have to do this in a trigger for Before Insert and Before Update.
Does the validation require data from another system? The common method to address this is data replication. This may seem like the easiest path. Take the data from the external system and update a custom object in Salesforce. That way you can use your Apex triggers to do the validations, or even relate records to the custom tables and use the Salesforce Validation Rules to keep it as a configuration! This is a dangerous and slippery slope. While it may be appealing to have all your data from other applications pushed into Salesforce for validation rules, reporting, and other operations, consider the following factors. First, why does the other system exist? What function is it providing that Salesforce does not? The second concern is around mastery of the data. If you are replicating data, make sure that only one system is the source of truth for the data.
So, as you work with validation rules, keep these questions in mind:
What am I trying to validate, and why? Is it for data quality or business process?
Is the data all related to a record that is being edited through lookups?
Will additional data that is not available through a lookup be needed? Or will I need to get unrelated data?
Does data need to be brought in from another application?
And always remember: Why make it code when it can be configuration? Why make it Configuration when it can be Data-driven? Why make it Data-driven when it’s included in the platform already?
About the Author
Dan Curry serves as our Director of Global CRM Delivery and Architecture with over 14 years’ experience in creating specialized clients solutions in process automation, data-driven application design, and team dynamics. He holds multiple Salesforce and industry specific certifications. Outside of his professional life, Dan spends time with his family, is an active minister in his local church, and practices Gadi Kempojitsu and Krav Maga where he is both an instructor and mentor.
Daniel Curry
Director, Global CRM Delivery and Architecture
St. Louis, Mo