Your data is one of the most important assets your company has. It’s how you track revenue, decide who you are (and are not) going to market to, get ahead of problems before they happen, and stay in touch with your prospects and customers alike. A clean, well-thought-out database is essential to the success of any business. Choosing the right or wrong tools to model your data within your database can either position you for success or set your company back significantly.
The above is true for any CRM, but the conversation is especially relevant to HubSpot with its recent string of CRM functionality releases — namely, Custom Objects as a CRM feature.
Custom Objects is a long-time offering for most other CRMs, and if you’re a HubSpot user, this new functionality may have you asking yourself if you should dive in and create a custom object based on your own previously unaddressed or misaddressed data needs. The answer to that question may be yes, but first, we recommend looking at the question differently. Jumping headfirst into a custom object solution could have long-term data implications that may not be easily reversed if needed.
First, let's take a minute to define the primary ways to store data in HubSpot.
Think of HubDB as a spreadsheet that can interact with multiple visitor-facing tools in HubSpot. Made up of rows, columns and cells, HubDB does well with staff directories or resource centers that are part of your site, for example. Equally as important, HubDB allows for the easy editing, organization and use of the information for users on the back end of your site.
Chances are that you’re already very familiar with timeline events, as many native integrations and HubSpot itself utilize timeline events to store and display information on object records. The caveat with timeline events is that they are a point in time and immutable, meaning they cannot be changed. An example of a timeline event would be a phone call that took place — you wouldn’t go back and change the specifics of a call length or the time it happened, for instance. Timeline events can also be referenced as criteria in lists, workflows and reports from within HubSpot.
This method of storing data allows information from other systems to appear on an object record within HubSpot. The cards appear on the right sidebar of an object record and allow you to view the data without ever leaving HubSpot. Unlike timeline events, cards are dynamic, meaning they will change over time as the other system feeds data updates. Also unlike timeline events, cards cannot be used in lists, workflows or reports.
An example use case for CRM Cards is if your organization was using something other than HubSpot to manage support tickets — you would still want users within HubSpot to know there’s a ticket associated with an object, but they shouldn’t be able to edit it and the reporting on that information is handled elsewhere.
Properties are related to an object (e.g. contact, company, deal) and allow you to store information in a variety of formats. Again, you’re probably already familiar with creating and managing properties in HubSpot (or another CRM). You also know that properties can be a very powerful tool and can allow you to accomplish very specific goals based on your unique company data.
The use cases for properties are endless, but the most common is storing any piece of data that is unique to your company. For instance, if you sell flooring to homeowners, you may need to associate square footage with that customer. The important thing to note here is that this is a one-to-one relationship, meaning one customer has only one square footage property associated.
Custom objects is the newest data storage method within HubSpot. It allows you to represent and organize your data based on your unique and sometimes complex business requirements. Your portal comes equipped with standard objects and custom objects live right alongside, allowing you to store/update data, source reporting, build automation around, and anything else you can do with a standard object.
Let’s use the same example we used before and change the prospect — now you’re not just selling to homeowners, but also property managers who want to buy flooring for potentially dozens of different properties. This means, square footage is going to be different in every scenario, but still only related to one contact/company, creating a one-to-many relationship. Because of that one-to-many complexity, the best solution for managing those properties and their square footage may be a new custom object.
Now that you’re up to speed on the different ways to store data in HubSpot, how do you decide which is best?
Custom objects may seem like the most customizable/powerful/robust option, but not so fast! Before landing on custom objects (or any data solution) we recommend that you first take a couple of steps back and ask yourself some key questions. Let your answers help you arrive at the best solution for the data in question.
If your answer is yes, your best bet is to use HubDB. HubDB is a powerful tool designed to store data for the purpose of publishing the data on your site. You can use properties to display data using personalization tokens or smart content, but HubDB is the best solution for managing large data sets meant to be visitor-facing.
Also referred to as the “Source of Truth,” where is the data primarily updated, created, and viewed? Answering this upfront is important as it will dictate important steps and paths for your data down the line. Thinking through this will also help you visualize working with the data in different environments and how they relate to each other at the outset.
Here are three possible answers to this question:
Answer #1: Data will be created/edited/worked with outside of HubSpot and does not need to be edited inside of HubSpot.
With this answer, you’re simply looking for the data to be viewable within HubSpot as a reference point for those working within the tool. If the data referenced in this use case is immutable (representing a specific moment in time and should not be changed), then you might be utilizing timeline events. If the data is dynamic (data will update and change over time) then you may decide to go with CRM extension cards.
Answer #2: HubSpot will be the primary source of truth for the data and the data does not play a role in other databases.
At this point, you have another important question to answer: Is the relationship between records and data one-to-one or one-to-many?
We went through an example before of a one-to-one versus one-to-many relationship, but let's look at it a bit differently. Does the data simply represent an aspect of a contact/company/deal or is it more complicated? Like a subcategory with its own aspects specific to itself? If the answer is the former, you can use custom properties to attach that information to the object in question (one-to-one relationship) and if it’s the latter, custom objects may be the data solution you're looking for (one-to-many relationship).
Answer #3: Data will be primarily created outside of HubSpot but needs editable ability from within HubSpot.
Answers #2 and #3 are related by the fact that you’re most likely deciding between custom properties and objects. However, there’s an additional level of complexity with this answer because we’re now approaching the subject of getting the data into HubSpot and storing it in a workable manner within the platform.
So, see answer #2 AND think through what it might mean to port information into HubSpot — this might include integrations, periodic data imports or manual record creation/updates.
Going through the above Q&A before arriving at a storage method will help you think about your data solutions in the context of HubSpot in a more all-inclusive way. While the above questions aren’t exhaustive, they hit the major points you should be taking into account when approaching a new set of data. They will also help you and your database stay on track and avoid making knee-jerk decisions that can lead to a potentially inoperable system for sales, marketing and anyone else that depends on a clean and workable model (which should be everyone!).
