Field naming convention for Salesforce and database tables

In this blog I’ll take you through a variation of a field naming convention for Salesforce that we use at ProvenWorks and recommend for use within Salesforce systems. To be clear we’re talking about the API name (or underlying table names) and not the labels that are exposed to users.

I want to stress that the most important thing is to have a field 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 convention of your fields. On a new field creation, Salesforce first asks for the label. It then creates an API name based on this label. This means 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 because developers using this ‘convention’ will always assume that the API name matches the label.

Naming conventions

Field names should use Upper Camel Case or Pascal casing. Here’s an 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”. We’ll get onto verbosity in naming later.

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 blog 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 field naming right alone. Bounce the ideas and then finally make sure the actual text is reviewed 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.