Field Naming convention for Salesforce.com and database tables

UPDATE Jan 2022 – Check-out the revised version of this post on our company blog at https://provenworks.com/field-naming-convention-for-salesforce-and-database-tables/

Below is a variation of a naming convention that I use within database and Salesforce.com systems that I manage, to be clear I am talking about the API name or underlying table names and not the labels that are exposed to users. I would like to stress that the most important thing is to have a naming convention what that convention actually is is of secondary importance. You will know that you have a good convention when you get the field/API name correct >90% of the time without actually knowing the table well simply because you know how it would have been named by its purpose.

Name your fields

If you’re reading this then you’ve probably already determined that you need to think about the naming of your fields. On a new field creation Salesforce.com first asks for the label. It then creates an API name based on this label, thus you can get:

Label=”Last 2 letters of Mother’s maiden Name”,
API name = “Last_2_Letters_of_Mother_s_maiden_Name__c”

Note that the spaces and apostrophe all become underscores making the ‘s’ stand on its own and the API name overly long (those underscores aren’t helping us at all). Also if the label changes (e.g. “2”->”two”) then confusion ensues as using this ‘convention’ the developers will always assume that the API name matches the label.

Naming conventions

Field names should use Upper Camel Case or Pascal casing, excerpt from http://en.wikipedia.org/wiki/CamelCase.

“CamelCase (also spelled “camel case” and sometimes known as medial capitals[1]) is the practice of writing compound words or phrases in which the words are joined without spaces and are capitalized within the compound — as in LaBelle, BackColor , or iMac. The name comes from the uppercase “bumps” in the middle of the compound word, suggestive of the humps.”

Try to avoid using abbreviations unless they are very widely used i.e. Id is fine instead of Identifier, Pro_Serve is not a good abbreviation of Professional Services as it is not consistent in its number of characters for each word and “Serve” is not a known abbreviation of “Services”. See later about verbosity in naming.
Acronyms are treated as if they were words, so SFDC Account Id would become SfdcAccountId – whilst this one isn’t intuitive it is necessary to properly separate the words out correctly. If SFDC were treated as all capitals many tools would (like SSRS) convert it to “S F D C Account Id” which is ‘more’ wrong. In this example “SalesforceAccountId” would be best.

Grouping

The underscore (_) character can be used after a field prefix to logically group fields together for example:

Software_Amount becomes Amount_Software
Maintenance_Amount becomes Amount_Maintenance
Training_Amount becomes Amount_Training

This grouping means that when fields are sorted alphabetically logically related fields appear together, very useful in implementations with >150 fields. Grouping is easily achieved by slight word re-arrangement for example; although we would usually verbally say “Date Created” here we name the field CreatedDate.

Grouping (underscore) isn’t absolutely necessary for field ‘pairs’ for example CreatedBy and CreatedDate or Contact.AccountId and Contact.AccountType (as the two fields will always be populated together). However if you anticipate other fields being added to this theme then grouping can be beneficial and makes reviewing the column/field list much easier.

Choice of words & Verbosity

This only outlines the conventions for naming, the actual choice of words is a task best proposed by one individual and then reviewed by others to ensure that the words are a good reflection of the purpose of the field without extra clarification. It is very rare that an individual gets the naming right alone. Bounce the ideas and then finally have the actual text review for typos (!!!).

However great the temptation to “quickly create a field” you should always resist, spending literally a few minutes carefully considering the naming will at a minimum save you time later and more importantly prevent a field being misinterpreted and thus wrong business decisions being made.

Remember it is better to be unambiguous and have a long field name than a short field name that is open to interpretation. If a developer complains that it takes too long for them to type a long field name then I’d suggest they’re in the wrong profession if they struggle typing a dozen extra characters.