Spring Training: Working with Custom Fields in Salesforce

February 28, 2014 John Gorup

custom fields in salesforce

Sports fans know this time of year as the Baseball Spring Training season. This is when ballplayers from the thirty Major League teams escape the cold weather and gather in Arizona and Florida to prepare for the long season ahead. All the players have been honing their skills since childhood – still, they use this time to focus on one thing above all: fundamentals. Building a solid foundation of the basic skills of the game like catching, throwing, or swinging the bat, allows the players to concentrate on winning when the competition is most fierce. It is in the spirit of Spring Training that we are sharing a series of blogs focused on the fundamentals of salesforce administration and development.

The most obvious skill to start sharpening is the creation and handling of custom fields in Salesforce. If you have spent any time in Salesforce at all, chances are one of the first things you have done is added a custom field to a standard object. This activity is fun and easy – perhaps a bit too easy. Consequently, I have seen several old salesforce orgs paralyzed by gobs of fields – many with poor descriptions, no standardization, no help text, and redundant to other fields.

spring-trainingTo understand good fundamental practices around  custom fields in Salesforce, I polled a team of Appirio All-Stars on the finer points of custom fields and compiled their advice here.

Salesforce.com MVP Rhonda Ross leads off: before adding any new field, be sure you understand how it will be used and maintained.

Speaking of adding the new field, Andres Glueksmann, MVP and father of the True to the Core movement, reminds us to think hard about the field label. Try to make it slim and neat, as long labels will make your page layouts ugly and confuse users. Sometimes dropping the “Date” for a date field label (for example) results in a cleaner User Interface. You know it’s a date field because there’s date in it, so you do not need to say “{X} Date”? For example: “Record Needed by Date” vs. “Record Needed by”.

Add help text whenever the field usage is not completely obvious. Peter Martin said to use the description field to record why the field is being used, and whether it is just for reporting purposes as well as being populated via workflow or a trigger.

Consider whether it would be beneficial to have a field’s change history tracked.  Remember by default, only 20 fields can be tracked per object (but this limit can be extended if necessary).

When creating fields, the default is to add them to all page layouts.  Don’t automatically accept the default.  Be selective when adding new fields to page layouts. Sometimes, fields may not be needed on any page layout (for example, fields created for integration, or formula fields used for reports.) Newly created fields that are added to page layouts are placed at the bottom of the first two-column section, except for long text area fields that are placed at the bottom of the first one-column section.   After adding fields to a page layout, remember to review its location with usability in mind. Fields used only for troubleshooting should go in the System Info section of the layout.

The Appirio team also had a lot to say about picklists and multi-select lists. Rhonda added: picklists are better than checkboxes for Yes-No questions because they have an explicit ‘No’ answer.

Multi-Select Picklists should be used with care; they are very difficult to report from effectively. A set of checkboxes can be an optimal replacement if the number of options isn’t too many (use one checkbox per multi-select option).

When adding picklist values, remember to select which record types need the picklist value. Don’t automatically add them to all – but always add the value to at least one.  Jarrod Kingston added: if a picklist field has many options, try to think of adding a controlling picklist field to make selection easier. Jarrod also thinks multi-select picklists are ugly.

Finally, about formula fields, Joshua Titus added: don’t over use cross-object formula fields. You don’t really need to see everything on one page. You can use lookup hovers which provide just as much or better insight than a formula field and doesn’t add cost to your cross object formula field limits.

There is undoubtedly a lot that can be written about the simple act of creating custom fields in Salesforce, but I believe the team highlighted some of the essential fundamentals. Stay tuned to this blog for more Spring Training in the fundamentals of Salesforce administration and development!

 App Development Best Practices Whitepaper

Previous Article
Salesforce Admin Hack Series: User Object
Salesforce Admin Hack Series: User Object

As Admins, we all use the User object right? So why not “hack” it up??  Michael Farrington and I return wit...

Next Article
Point to point integration tips for Salesforce
Point to point integration tips for Salesforce

By Mauricio Desiderio Salesforce is an awesome piece of software. It is amazingly extensible and configurab...