Simplify With Record Types, Field Dependencies and Validation Rules

Salesforce administrators should have the goal of simplifying and error-proofing the data-entry process for Salesforce users.  This makes for happier users, fewer day-to-day problems, and better data.  But User Experience is rarely a class at administrator school.  So here are some pointers to keep in mind:

User don't want too much data or too many options.

• For two column entry, users tend to want to see the entry progress linearly down one column, then the other, rather than zig-zagging from column to column.
• Fewer options in picklists are easier to navigate.
• Consistency is important for design, field naming and data entry.
• Data entry on keyboards should require few or no mouse clicks.
• Users don't want unnecessary options cluttering their screens.

One way to put this into practice is by making good use of record types, field dependencies and validation rules.

Record Types

Record types help users by limiting the number of fields available on the screen for any particular data.  If, for example, you have a Salesforce object called Equipment, you might want different record types for Electric Vehicle and Petroleum Vehicle because electric vehicles won't need to track gallons of gas.  Having different record types lets you customize the fields to be only what is needed for any given data set.

But record types are exclusive.  If you have Vehicle record types for Electric and Petroleum vehicles, what will users do when they need to select Hybrid?  You can simply add more record types, but at some point your list can get unwieldy if you aren't careful.

Imagine using a single object, Equipment, to track vehicles, computers and more.  If every vehicle type and every computer or mobile device type, etc., requires its own record type, the list could be endless and difficult to maintain as new equipment types become available in the future.  In this case, broader record types can be used and other database design considerations can be employed to help users view only the options they need for their data.

Field Dependencies  

For a record type of Computers, we might offer a picklist to specify whether a piece of equipment is a desktop/laptop or a mobile device.  A single subsequent picklist can offer options tailored to each device. With any two picklists, you can define a field dependency that limits the options available on the second list depending on the selection made from the first list.

For example, an Equipment object with a picklist offering Desktop/Laptop and Mobile as options, might have a single multi-select picklist with status descriptions.  You don't want Mobile device data showing up with a status of "bad hard drive", but you can remove that option from the picklist for all Mobile data by defining which options to include based on a field dependency.

Validation Rules

As useful as field depencies are, not every data entry option can be expressed as a picklist.  For other fields, validation rules can provide similar limitations.  For example, if you have two Equipment data sources for temperature, one for freezers and one for heaters let's say, the range of valid data will be different for each of them.  With a validation rule, you can provide a single field, but check that the values make sense for different kinds of data being entered.

By designing a data model that makes good use of record types, field dependencies and validation rules, you can protect your database from bad data and give users a better experience as well.  If you can eliminate extraneous options, users will not have to sift through fields and choices to get their work done, nor will they have to go back and check whether they put in a negative or positive value for that freezer temperature because the system will do all that for them and improve not only the data quality, but also the user experience.