Think of data validation as bumpers in a bowling alley. Validation creates an easier and more streamlined experience for end users to ensure they bowl a perfect 300. Data validation benefits end users as much as it makes the jobs of Salesforce Administrators easier. When end users run reports and dashboards with clean, comprehensive, and up-to-date data, their metrics will reflect it. In this post we will discuss the benefits of data validation, explain the different types and identify some best practices for getting started.

Data Validation Benefits

Requiring fields or restricting users from editing fields based on certain conditions is a building block to good data hygiene and completeness. At first, implementing data validation on your users might seem like creating an obstacle more than providing a helping hand. “Why are you forcing me to fill out this data? I just want to save my record and move on!” On the contrary, well implemented data validation should provide users with a sense of security – the system is there to guide them. Validation can help remind users to enter key pieces of data they likely have, but neglected to input. It will also ensure they cannot edit data that should not be changed, like financials that have already been reconciled with another system. Remember those bumpers – no one likes a gutter ball.

Types of Data Validation

Let’s talk about what types of data validation are available in Salesforce, and why we might use one over another.

• Require a field value upon record create. This is the strictest way to require a value, regardless of the user profile or what page layout it is on. It includes data coming in through your API/integration users. A good question to ask before requiring a field on create might be, can this record ever exist without a value? If the answer is an unequivocal no, then this might be the right solution. If the answer is “it depends” well, keep reading. Flexibility level: low. 
• Require a field value on the page layout or on the global action layout. Depending on your object and business processes, you may have many layouts. This solution gives you a few more options compared to the above, although it is still a blanket requirement. The only conditions here are whether a field is on a specific layout or not. Flexibility level: medium.
• Validation Rules on lookup fields. Not to be confused with general Validation Rules (more on those below). Validation rules on a lookup field allow you to limit which records your users can populate in a lookup field. You might do this to restrict your Account lookup where Type = Foundation on all Donations where Type = Grant. The system gives you the option to either prevent save when the criteria don’t match or notify the user. If notified, the user can still remove the filter or enter values that don’t match the criteria. Flexibility level: high, but feature is restricted to lookups only.
• Validation Rules (general). Validation rules are the way to require or lock field values conditionally. That means, if field X meets certain criteria, require a value for field Y. Or, if fields A, B and C meet certain criteria, prevent edits on field D. The sky is the limit here. Flexibility level: high.

Some examples of validation rules for nonprofits might be:

Validation Rule	Benefit
When a Donation is marked Closed/Won, prevent future edits on the Amount, Date, and Stage fields.	Your development and finance teams can ensure a smooth reconciliation process between Salesforce data and the data in their back office financial system.
If a Donation has an Amount above $5,000, require a value for the Solicitor field.	Your major donors and their gift solicitation process should be handled with care – if you assign Solicitors as part of your process, then require them on your major gifts.
Require either an email address or a phone number for new Contacts entered as donor prospects.	In order to communicate with donor prospects, your fundraisers will need at least one way to be in touch with them.
Enforce proper formatting for US phone numbers (XXX) XXX-XXXX.	A Contact record is only as useful as the valid contact information contained within it. Everyone who wants to interact with constituents or donors will benefit.
For a grantmaking foundation, prevent edits to grant fields for most profiles once the funds have been awarded.	Similar to the donation validation rule above, but this rule restricts based on Salesforce user profile.
Require a value for a dependent picklist based on its controlling picklist. For example, a Type picklist with sub-Type options.	The data quality for each Type will improve. All those who run reports based on these fields will benefit.

For additional examples of Validation Rules visit the Salesforce Help guide. 

Duplicate prevention tools are also categorized as a type of data validation, but we will not talk about that extensively here. In short, Salesforce has a native tool to identify duplicate records, and there are several third party products that proactively find and merge duplicate records in bulk. Include these tools as you evaluate where your users might benefit from validation. For more information visit Duplicate Management in Salesforce.

Data Validation Best Practices

Best practices for required fields:

• If you’ve set your field to require a value on the page layout, consider any Quick Actions that may be in use and require a value there as well. For example, if you require a field on the Activity page layout, identify where else activities are logged. If users are also logging activities on the Account or Donation layouts, make sure you require it on your Quick Actions as well.
• Many third party form apps have the ability to require values for certain fields, consider leveraging these tools to ensure clean data before it even enters your system.

Best practices for Validation Rules:

• Before activating any Validation Rules, run exception reports to surface records that do not meet your validation criteria. Clean/backfill that data before activating those rules. You may be surprised by how many legacy records do not meet your criteria. If your data is not cleaned prior to implementing Validation Rules, users may be required to enter data they simply do not have. If you prefer to leave those records behind, exclude them from the Validation Rule using Created Date or other criteria that groups them together.
• Integration users should generally be excluded from Validation Rules. If data is entering your system from FormAssembly, Click & Pledge, or other external systems, the record may be rejected if the data meets the criteria of your Validation Rule. However, there is no way for the end user to make the required changes. Add a line of criteria to make sure the rule does not apply to the user integrated with that external system.
• Similar to integration users, you may want to exclude System Administrators or other users performing data uploads through an Extract, Transform, Load (ETL) tool (e.g. DataLoader, Apsona) from your validation.
• Use friendly but clear wording in your validation error messages. If you are preventing your users from saving a record, consider warm wording like, “Oops! Were you trying to do X? Make sure you fill out Y!” Users may already be frustrated that they’re seeing that red text. Make your expectations clear, and ensure they understand the intent is to help them.

General best practices:

• Validation never replaces training and documentation. Communicate with your users about how they are supposed to use the system. Training will also provide you with an opportunity for users to give feedback on what is and is not working with validation.
• Explore all of the available options to validate data and make your users’ lives easier: leverage formula fields, default field values, and automation to reduce double entry and ensure data quality.

If you are concerned data validation will alarm users, consider starting with exception reporting. Using Report Subscriptions, create reports to run weekly with records missing key pieces of data based on the appropriate conditions. Have these reports emailed to the users who own the data. Once they get in the habit of filling out the data on a regular basis, they may welcome more sophisticated Validation Rules to require this data earlier in their entry process.

Summary + Conclusion

While there are many tools at your fingertips to perform data cleanup, consider all the options available for preventing unvalidated data from entering your system in the first place. These data validation solutions can help provide a positive experience for users entering data as well as for the admins managing the system. Keep the process iterative so you can stay close to your organization’s evolving business practices and needs. Turn those gutter ball gurus into super strikers!