Home

CIC Field Insights

Overview

We went through all of the fields that you currently have within HubSpot, and performed an audit on them.

We started by working to develop a naming convention for the fields.

A naming convention is an agreed upon set of rules to govern how to name current and future properties within HubSpot.

Typically naming conventions will provide key information in a specific order.

Disclaimer

Historically, we have been Salesforce Administrators where Properties are known as Fields. We did our best to translate the naming to HubSpot Properties, but we may have missed a few when writing this.

HubSpot Property vs Custom Object

One thing we noticed is that some of the fields seem like they would be better suited as a Custom Object.

When creating a property, it is always worth considering if it makes more sense to create a custom object. Take for example, adding a field to the contact for Contract Attachment. While you want this field to be associated with a Contact, it would also make sense for these contract attachments to relate to a Deal. Also, you might have multiple attachments that should be separate files.

Any of these reasons above make sense for us to consider a custom object called Contract over a custom property on a Contact.

I need a field now!

Image from Willy Wonka

All businesses move fast but using bad naming conventions can lead to properties being misinterpreted, poor decisions being made, duplicated data, or data never being collected.

Taking a few minutes to review the naming rules could save you hours down the line. Make life a little easier for future you!

HubSpot Property Naming Conventions

Best Practices

  • All properties should be unique. This will be mandated by HubSpot but worth putting first.

  • Names should start with an Uppercase letter.

  • Use title capitalization when naming a field.

  • Capitalize:

    • Nouns, pronouns, adjectives, verbs, adverbs and subordinate conjunctions
    • The first and last words of titles, no matter what the words are.

  • Lowercase:

    • Articles, coordinating conjunctions, and prepositions
    • The to in an infinitive.
    • The second element of a hyphenated compound.

  • Whole words should be used, and use of acronyms and abbreviations should be limited.

  • When creating a custom property, always complete the "Description", and the "Group". Descriptions should act as a guidebook for other or future admins and team members. Include details as to why the field was created, who requested I, and what is the end goal of collecting this information.

  • Avoid locality, or over specificity in the property name. Property names should be generic and not location specific.

  • Avoid special characters. This can cause issues with the API and calculated properties.

  • Avoid being too vague with a field name. Address for example is too vague, and should be more specific like Mailing Address - or even more specific like Mailing Address - City.

  • When referring to properties in relation to other objects, use "on" instead of "in". For example, Number of Contacts on Company vs. Number of Contact in Company. This is important because it helps to specify that it relates to the Object and not the actual company. Also, it helps to separate that this data isn't held within the Object but is made up of data connected to the Object.

Exceptions

Widely used and commonly understood acronyms and abbreviations can be used. They should be common across disciplines and knowledge properties though.

HubSpot Property Groups Conventions

Overview

HubSpot property groups are used to keep related properties grouped together. They are super helpful when connecting different properties together around a standard subject. One drawback though is that integrations automatically create new property groups, which can result in extra data and unneeded property groups.

Best Practices

  • Avoid using property groups as a form of tagging or data segmentation. Property groups shouldn’t be used to label specific pieces of information but instead used to organize into broad, logical sections.

  • Property groups are meant to organize data structures, not the data itself.

  • Property groups should be designed with all teams in mind.

  • Create property groups based on data types or business functions.

  • Keep names concise

  • Use title case

  • Avoid abbreviations

  • Align with Business Functions