Salesforce fields are so important to a successful implementation, yet you may completely forget to really think critically about these “building blocks” of your CRM. A good analogy is this awesome lego model of the University of Colorado (your entire Salesforce instance) and an individual lego piece (one field). Miss a few fields? The history building may fall to pieces if you’re not careful. Fields organize and display your data and prompt your users to input the right data in the right spot.
Out of the box, you have a long list of standard fields that cover the basics of relationship management. Standard fields come in all shapes and sizes from currency to URLs to encrypted text to roll-up summaries and much, much more.
You can expand the set of information captured and stored in your Salesforce instance by creating custom fields, which are available in all of the same shapes and sizes of standard fields. Custom fields can be added to standard objects (Contacts, Accounts, Opportunities, etc) as well as custom objects that you have defined and created based on your business needs. Enterprise Edition customers can add 500 custom fields per object! When you install an application to extend Salesforce functionality, in many cases custom fields will be added to your instance as well. These will typically have a naming convention that allows you to identify what application they are connected to. Being able to identify fields by a naming convention becomes important if you ever want to uninstall an application.
A few best practices in general for Salesforce fields:
Naming
Field names consist of two separate items: the Field Label and the Field Name. The label is what your users will see as they navigate through the system while the name is what is used in when referencing the field from the API. You will populate the Field Label and Salesforce will automatically create the name based on the label. The name will contain only alphanumeric characters and underscores and must be unique within your instance.
When creating a custom field, you want to put some thought into the label. It should be informative, simple, and distinct. Because the name tells users about the data they will find or put into that field, the label needs to clearly tell them about that piece of data. Field labels also play a key role in reporting. Thinking about what types of reports the field will appear in and how those reports will be used can help you to determine a label that users will be able to distinguish from other similar fields on that object or other objects when building and reading a report.
Help Text
The little orange ? bubble that appears next to each field on a page layout is a lifeline for your users. It guides them to input the right information into a field, so it’s really important to data quality. I encourage you to add help text to standard fields whenever the request of the user is not 100% straightforward and ALWAYS adding help text for custom fields. Help text is defined when creating a field and can be added or edited through the setup menu after a field is created.
Description
System Administrators, or any user with the Modify Application permission, can add and view descriptions for standard and custom fields. Descriptions are only visible in the setup menu and not visible to users on page layouts. Field descriptions serve as the guidebook for other or future administrators. Think of this as an investment in an administrator manual for your instance and provide a detailed description for all custom fields. Include details about why the field was created, who requested it, and what is the end goal of collecting this piece of data. Trust me, your future self will thank you for putting in detailed descriptions!
Field History
Sometimes, you want to know previous values of a field to ensure data quality or to understand changes over time. From the Fields tab on any standard object you have a button to called Set History Tracking. Once enabled for an object, you can select the specific fields to track – up to 20 fields per object. Whenever a user modifies the data in that field, the previous and new values will populate the History related list, which you should add to the page layout if you would like to easily access this information. You can also enable Field History for a custom object when you create the object or by editing the object after it has been created. Field History is a great tool for keeping an audit trail, but it won’t work with multi-select picklists or large text areas and you want to carefully pick the fields you track so that you’re creating value and not clutter!
A few related blog posts that you might also find helpful:
