The great thing about Salesforce is that it’s so easy to create. When you get started as a Salesforce Admin, one of the first skills you learn is how to create a custom field. After that, you’ll learn to create folders, reports, page layouts, record types, validation rules, automation, and approval processes – the list goes on! What do all of these have in common? They all need a name. Enter, Salesforce Naming Conventions!
The names you choose will almost certainly impact your org; names can be a help or a hindrance, as well as a source of frustration for admins and users alike. Poor naming conventions (or no naming conventions!) lead to confusion and poor data quality. They also increase the time it takes to locate information or enter data, and potentially create security problems too.
On the flip side, a good name can eliminate confusion, save time, and make it easier to grow your Salesforce in the future. This article will explore how to create quality naming conventions, as well as how to enforce them.
What Are Salesforce Naming Conventions?
A naming convention is the generally agreed format when it comes to naming things in Salesforce. Typically, names will provide key information in a specific order.
Naming conventions follow rules to provide us with more information, and they aren’t just used in Salesforce; we see them every day in our personal lives. For example, if you’ve ever registered for a college/university course, you may have seen something like this:
That’s a lot of data to look at, and because we’re going to have lots of students registering for these classes, we need a unique identifier for each one. That’s where the naming convention comes in.
In the image above, we’ve added a new column (Course ID) which serves two purposes; it is a unique identifier for each course, and it also tells you everything you need to know about that course:
- LIT identifies which department this course falls under.
- 101/102 identifies the specific class.
- A/B identifies which classroom (Room A or Room B).
- 22/23 identifies which year the course is offered (2022 or 2023).
The naming convention uses consistent, repeatable rules to create a name that is both unique and communicates a lot of information in a very small data set. Now, how can we apply this same concept to Salesforce?
Using Naming Conventions in Salesforce
One of the very first things I learned to do during my initial Salesforce Admin training, was how to create a validation rule. Salesforce validation rules can range from simple to incredibly complex, but they all have this in common: a name, a description, a rule, and an error message.
Validation rule names and error messages are excellent places for naming conventions. Being diligent will save you a lot of headaches in the future, especially when users send you screenshots of the pesky error messages they need help with interpreting.
This is a horribly worded error message to begin with! There’s no indication of where it has come from, what caused it, what object the user is on, or which date this error is referring to. We can fix part of this simply by putting more detail in the message. As for the other part, we will fix it by using a naming convention. Just prefix each validation rule with a numerical code and include that number, as well as the name of the object, in each validation rule error message.
After applying a Naming Convention to your validation rules, it will be much easier to help your end users troubleshoot any problems they might be having.
In this example, we’re looking at a screenshot of an error message – the same as before. But this time, there are no questions about where this message came from, or what the end user was trying to achieve when they got this error. As the admin, I can see instantly what happened. If this were a more sophisticated rule (or one I think the end user should not have received), I’d know exactly which validation rule to look at – I wouldn’t even have to scroll or hit command+F on my keyboard – this is rule #5 on the Opportunity.
Other Places to Use Naming Conventions
Any place in Salesforce where a human types in a name (rather than an auto number) is a potential home for a naming convention. This goes both for admins and users.
Email Templates, Flows, Process Builder, Public Groups, Roles, Profiles, etc. – many managed packages use a naming convention in the API Name of their custom fields.
Some companies use the MEDDIC sales methodology to create custom fields on an Opportunity. This is a great place to use a naming convention in your API Name – just add “MDC” as a prefix to the API Name:
The most common place I see Record Naming Conventions in use is on the Opportunity Name field. Sales reps are notorious for creating poor names for Opportunities. A common convention I see is:
Account + Type + Close Date
This naming convention on Opportunities allows a sales manager to include a lot of information in one field, without having to click on the Opportunity or have a lot of fields in the report, list view, or related list.
Looking at the name of an Opportunity with this naming convention instantly tells you a lot about it, while keeping the clicking and scrolling to zero. Some companies also like to include Partner Name or Amount (though formatting Amount can be tricky.)
A quick note about enforcing naming conventions – the above Opportunity example uses a flow that updates every time the record is updated. So even if a user manually changes it, you’ll find that things change back again upon clicking “Save”. However, if you need a naming convention your users have to type in manually, you can use a validation rule to confirm they have included the right data in a field, or RegEx to confirm if that data is in the right format.
Summary
I really hope that you’ve found this helpful! Naming conventions make life so much easier and can be used in so many places in Salesforce. It’s another of those simple-to-implement features that have a big payoff, especially for busy solo admins. Please let us know your favorite way to use Salesforce naming conventions in the comments below!
Comments: