by Amanda Bailey
In a previous post, we did a deep-dive into cleaning up Salesforce fields using a free resource called Field Trip. We discussed the importance of removing fields that are not used or updating them to be required. In today’s post, we will be taking cleanup a step further by discussing the importance of naming conventions. It isn’t the most glamorous of topics but an administrator who can implement naming convention rules successfully will set their business up to be extremely successful.
Relational Databases
Salesforce, at its core, is a relational database that stores data related to your business. Don’t be intimidated by the term “relational database” all a relational database consists of is a database that can recognize relationships between the information being stored. This makes it very simple for users to track information, acknowledge trends, and run reports to keep a finger on the pulse of the business. Salesforce took it to the next level and created a beautiful user interface (UI) that allows every day users to understand the relationships without having to run queries. Now that you have a baseline understanding of a relational database, we can elaborate on why it is important.
Database administrators follow very stringent rules and some even create documents that outline how to name their tables (objects) along with the rows (fields). This practice helps them to query the data in a simple way and allows them to write scripts and troubleshoot issues in the scripts without having to verify every field and object name. As Salesforce Administrators or Business Analyst, often time’s new objects and fields are created very quickly in order to satisfy an urgent business need. Doing this without having a set of naming conventions can cause multiple issues for your developers, data analysts, data warehouse engineers and new administrators.
Potential Issues:
- Broken Code: using different rules to create the API name or updating the field label and API name without following guidelines can break code
- Duplicate Data Points: I’ve seen the same field created twice because there was no specific way the field should be identified
- Vague Fields: the data analyst could use the wrong field to pull in data for global reports because the fields all have similar names
- Report Confusion: creating multiple custom reports that all do the same thing because the naming didn’t properly identify what the report does
Naming Conventions
A misconception with Salesforce and relational databases is that naming conventions are primarily the responsibility of the developers. However, often administrators are the ones that are creating custom objects, fields, reports, dashboards, workflow rules, profiles and page layouts. Provided below are examples of naming conventions and examples.
|
Area
|
Naming Convention
|
Example
|
|---|---|---|
| Objects | NameofObject (This is the API name not the label) | ResignationForm |
| Fields | NameofField (This is the API Name not the label) | ResignationDate |
| Reports | Object with Object Object with without Object |
Accounts with Contacts Accounts with without Contacts |
| Dashboards | Department – Description of what the dashboard presents | Sales – Overall Sales Team Fiscal Numbers |
| Workflow Rules | What the Rule Does | Opportunity Status Updates |
| Profiles | Department Function | Sales Vice President |
| Page Layout | Use or Department Object Layout | Qualification Lead Layout Marketing Account Layout |
General Naming Convention Rules
When establishing naming conventions there are different ideas around what is and isn’t important. Below I have listed the four main rules to prevent major issues.
- Should be specific and not vague
- There shouldn’t be any misunderstanding when reading the name of a field, object or report regarding what the function is. Having the naming as predictable as possible leaves little room for error or the need to ask what a “Resignation Form” object is. If there is an object or field that is being created that has a similar name to another field or object that needs to be separate a good tip is to insert the department name at the beginning. For example, if Finance really wanted an object called “Lead” that was for something entirely different you could call it “Finance Lead” instead so there wouldn’t be any confusion.
- Consistent
- When naming Objects and Fields the label can have regular spaces but the API name should follow either the CamelCase rule or the Snake Case rule. This will make it much easier to query and for your developers to write code against your fields. The administrator team, business analysts and developers should all agree on whether to use CamelCase or Snake Case.
- CamelCase utilized for the API name (CamelCase: is writing words without spaces or hyphens and capitalizing each word. Example: WebPortal)
- Snake Case utilized for the API name (Snake Case: is writing compound words by inserting an underscore without spaces between each word with the words being lower case. Example: web_portal)
- When naming Objects and Fields the label can have regular spaces but the API name should follow either the CamelCase rule or the Snake Case rule. This will make it much easier to query and for your developers to write code against your fields. The administrator team, business analysts and developers should all agree on whether to use CamelCase or Snake Case.
- No Special Characters
- Using special characters can cause breakage in code and it can make it very difficult to run queries against field and object names.
- The only time I have found it necessary to use special characters is sometimes when creating custom Reports, creating Report names and Dashboard names. When there is a character limit and you need to be specific sometimes using w/, w/out or & is necessary.
- Descriptions
- Descriptions should be populated 100% of the time. Although the field or object should be named in a way that will be specific enough so that anyone coming into your company understands what the field or object is used for the description should include any additional information about the field such as what department the field is used for. The description is also utilized in cleanup and can be key in identifying if a field is valuable or not.
Record Naming Conventions
Working with sales teams you quickly understand that their focus is the “hustle”, the feeling of going out daily meeting with customers, closing deals and in turn increasing their revenue. Whether they work in Salesforce, have an excel sheet or write down the names of their clients in a notebook they know who the big fish are. If there are three opportunities in Salesforce named “Enterprise 2k” then it will be very difficult for them to identify which one is theirs or for their sales leaders to understand which deal belongs to which rep.
Although for an admin it would be as simple as running a report or looking at the owner of the record, that isn’t always the first thought in the mind of leadership during a sales huddle. I have personally had to attend sales meetings to pull up which deal belongs to which rep because they all decided that using “5k+ IMPORTANT” was the best way to identify their specific deal.
Record Naming Conventions
|
Area
|
Naming Convention
|
Example
|
|---|---|---|
| Opportunity | Account – Product Quantity | Wal-Mart – Plungers 500 |
| Account | Actual Company Name | Wal-Mart |
| Lead | First Name Last Name | Michael Peters |
| Contact | First Name Last Name | John Smith |
It might seem silly that Account is mentioned in the table, but there have been several headaches arise from people naming Accounts with acronyms (if they put CC instead of Coca-Cola) or using slang (Coke). It makes it very difficult to scrub (search Salesforce to prevent duplicate records from being created) the system and leaders might not realize that a large deal is in the works. The main problem that arises is one sales rep owns Account “Coca-Cola” and another rep owns “Coke”. The customer experience is now tainted because they have two different reps suggesting and offering different deals.
The same issue comes up with the Lead object and the Contact; some reps don’t want to have their customer’s information in the system. They would prefer to keep the information to themselves so they might put “Michael N/A” instead of “Michael Peters” or “Unavailable Unavailable”. This type of problem needs to involve leadership because the reps need to understand that the contacts belong to the company. The last thing leadership wants is for someone to leave with million dollar contacts and your company doesn’t even know who they were talking to.
Deciding and implementing naming conventions is easier when you have a fresh instance, but is still possible in an older org that already has customizations. With a new or an old Salesforce org the business will need to come together to determine what naming conventions should be used. The Administrators, Developers, Analysts and leaders need to understand the importance of the new naming conventions, why it is important and when the team will roll it out. So get together with the team, identify what naming conventions and nomenclature the business will use and when it will be implemented. This process will be slower if it is an existing org but in the end, the benefits won’t just be for the Salesforce team but for the business as a whole.