Salesforce Object and Field Naming Conventions and Why It Matters

Something that is always overlooked is the importance of a standardized naming convention for all objects and fields built on the Salesforce platform. This might seem trivial and unnecessary at first glance, but in the mindset of designing a backend that is easy to understand it is imperative to implement a standard. This consistency in naming conventions will pay dividends during the development and continued maintenance of your solution as the API name will allow the team building to infer data types with ease. Additionally, if your Salesforce instance is just one part of your tech stack and you have a reporting team that is responsible for managing Salesforce data in a data warehouse that team will be singing your praises for consistency. As you can see the theme here at Campfire is always admin serviceable design.

What’s in an object's name?

Our object naming standard recommendation is pretty simple. Simply remove the underscores. For instance if you had an object called Opportunity Competitor the API Name would be OpportunityCompetitor__c. That simple. One other design recommendation that we often implement is if you are using an auto number for your record name simply rename the field Code - it makes your system just a bit more intuitive to end users.

You gave that field what name?

Yes, creating a custom field is the easiest thing to do in Salesforce, but by spending just a few additional seconds during that creation process you can set your team up for future success. Before we get into the naming convention methodology we have a few reminders for creating fields.

• Add help text if the field is displayed to end users and would not be understood based on its label alone.

• Add help text if the field is a formula and it is important for end users to understand the mechanics of how it works

• Add a description if the field’s purpose is vague based on simply its name.

• NEVER EVER GIVE 2 FIELDS THE SAME LABEL!

• REMOVE THOSE UNDERSCORES!!!

Below find our API naming convention structure for field api names. We have found that implementing this structure allows for quicker development and easier system administration.

Custom fields API naming conventions

Boolean

• Boolean fields should be prefixed with the appropriate verb that describes the nature of the field. This entails prefixing the API name with Is/Are/Has…etc.

• Example: field that indicates if a record is Active should have it’s API name as isActive.

• Example: field that checks if an Account has Opportunities should have its API name as hasOpportunities.

Date

• Date fields should be prefixed with Date_.

• Example: field called Signed Date. API Name would be Date_Signed.

Date/Time

• Date/Time fields should be prefixed with DateTime_.

• Example: field called Sent Date/Time. API Name would be DateTime_Sent.

Formula

• All formula fields should end with _f. This enables ease of understanding the field type when building flows and writing code.

• If creating a boolean formula field the API name should adhere to the naming standard for a boolean field with the _f at the en.

• Example: if there is a field called Total Amount the API name should be TotalAmount_f

Lookup & Master Detail

• Fields should indicate that they hold an Id. For instance, if you have an Account relationship the field should be called AccountId. Some teams like adding an ending of _L or _Md to indicate what type of relationship the field is.

• When creating a relationship field it is important to set the Child Relationship Name (see screenshot below if unfamiliar with what is being discussed Fig 1.0). The child relationship naming convention differs between a singular lookup and a junction object.

• Singular Lookup Example 1: imagine that you have an object called Case Status History that tracks the Status changes of a Case. The object is a child of a Case. The Child Relationship Name should be set as CaseStatusHistoryAsCase.

• Singular Lookup Example 2: imagine that you have a lookup to a user on the Account object called BDR. The relationship name should be set to AccountAsBdr.

• Junction Example: imagine that you have an object called Opportunity Competitor. This object is a junction between Accounts and opportunities. On this object you have a master-detail relationship with the Account called Competitor - the Child Relationship Name would be OpportunityCompetitorsAsCompetitors. The Child Relationship name for the master-detail relationship with the Opportunity would be OpportunityCompetitorsAsOpportunities.

Percent

• Percent fields should indicate Percent in the API name. Most individuals will label a field Discount % and then click tab to set the api name as Discount. Think about how confusing this is when writing validation rules or automation.

• Example: field called Discount % would have it’s API name as DiscountPercent.

Roll-Up Summary

• All roll-ups should end with _RU. This enables ease of understanding the field type when building flows and writing code.

• Example: if there is a field called Total Amount the API name should be TotalAmount_ru