At HubSpot’s Inbound conference in 2020, they announced the addition of the Custom Objects feature to their CRM platform. For the first time, HubSpot users (with at least one enterprise-level HubSpot Hub subscription) got full control over the data they could store in their CRM. As a result, the number of things you could do with the CRM and platform as a whole exploded.
But HubSpot Custom Objects can create technical debt and friction in the same way and at the same magnitude that they increase the flexibility and power of your CRM. In the year since the feature’s announcement, we’ve implemented, integrated, and live-synced more HubSpot Custom Objects than we could count (thanks to our Custom Object Interface tool). At the same time, we’ve seen almost every way it can go wrong.
Does it even matter if I mess up a Custom Object?
Want the short answer? Yes. For starters, you don’t want to create a Custom Object, build out all the properties, add data, perhaps even use it, and then realize you need to delete it. That’s because the amount of work you have to do to delete it will make you disillusioned with the feature. Compounding this issue, you can’t change important information in your Custom Object schema, like the object’s name and labels, after you create your object.
That information is crucial to using that object, and you want to make sure the Custom Objects you create align with the real-world thing you’re trying to track and the process it’s involved in. It’s the process that enables and drives the utilization of your Custom Object. Once you lose sight of that, adding Custom Objects to your CRM can only add friction and technical debt. To put it simply, it’s a waste to create a Custom Object without also having processes that support it. Without that, no one will use the object.
So what can go wrong and how can I avoid it?
1. Creating a Custom Object without thinking about it first
This is the single most common mistake we’ve seen. Custom Objects are really exciting and many HubSpot users want to jump in and get to customizing. The result? Hastily built objects that are stricken with typos and lacking in supporting processes sit unused in CRMs. The time-suck of deleting every single property, record association, record, object association, and anything else that wasn’t in the initial schema when you created the object. Effort spent figuring out hacks to make a bad Custom Object work with little value provided in return.
Solution:
You want to create a good, correct Custom Object the first time to avoid all of that. So, you need to do everything on paper first. Before you even touch a Custom Object builder, like the Custom Object Interface, or configure an API call, outline everything.
- Draw the ERD (Entity-Relationship Diagram) with the new object in it
- Lay out your whole schema in a spreadsheet
- Outline what a sample record of your object looks like
- Figure out which business processes your object fits, how it fits, and what it’s used for
If you do all of those things, you'll avoid creating a bad object--and all of the friction and technical debt that comes with that mistake.
2. Assuming Custom Objects have all of the same functionality as HubSpot’s standard objects
With greater customization comes great control. At the same time, that comes with less out-of-the-box functionality than you’d get from HubSpot’s standard objects (e.g., contacts, companies, deals, and tickets). You’ll need to replace a few things from standard objects when you create a Custom Object (depending on what you’re using that object for, of course):
-
A record ownership property: Custom Objects don’t come with a HubSpot Owner property built in. In most cases, someone is responsible for a Custom Object record. If an actual person is going to be responsible for any Custom Object records, this is something you need to add.
-
A team assignment property: Just like with ownership, there’s no out-of-the-box property to assign Custom Object records to a team.
-
Activity properties and automation: No “Last Activity Date” or “Next Activity Date” for Custom Objects out of the box. If you want to track activity on Custom Object records, you not only need to create the property, you need to build the automation that sets those properties.
-
Other automatically set HubSpot properties: Session tracking, email tracking, stage advancement dates, etc. If you plan on tracking any of this on your Custom Object record, you’ll have to create and find ways to set those properties yourself.
Solution:
How do you avoid these holes? It goes back to being clear about the business case and what you’re using a Custom Object for. These limitations particularly affect your ability to do and track outreach with Custom Object records, so we advise doing everything you can to use the standard objects if the goal is to enable an outreach process.
3. Creating a Custom Object from an incorrect schema configuration
Even with tools that make it extremely easy to work with Custom Objects, there’s still a level of understanding you need to have to make sure you do it correctly. Terms like “Primary Display Property” and “Searchable Properties” come from the more technical side of CRM administration. They can cause confusion when working with Custom Objects, especially when doing it for the first time. There’s some nuance to what you should do with each part of a Custom Object schema.
Solution:
Avoiding the mistakes those nuances can cause all comes down to understanding the anatomy of a schema:
-
The object name: This is a back-end name that the HubSpot system (barely) uses to identify your Custom Object. It isn’t something that appears in many places. It should usually match one of your labels. It cannot be edited after the Custom Object is created.
-
The singular label: The word the HubSpot UI uses to refer to a single record for your Custom Object. It cannot be edited after the Custom Object is created. You can find it on the button you click to create new Custom Object Records, on the sidebar that facilitates the creation of a new Custom Object Record, and even in the object selector for Property settings. Here’s some examples:
-
The plural label: The word the HubSpot UI uses to refer to multiple Custom Object Records. It cannot be edited after the Custom Object is created. This gets used in record “views”, reports, even in settings. It’s the part of the schema most used by the HubSpot UI. Here are some examples of where the Plural Label pops up:
-
The primary display property: This is the key identifying property for your custom object records. It’s usually a name or ID. This is the property that is most prominently displayed in your Custom Object record summary. It’s also searchable and required by default (more on what that means later). The items circled in the examples below are the main places you’ll see the Primary Display Property:
-
The required properties: These are the properties that must be filled with data for someone to be able to create a new Custom Object record. These are the properties that are crucial to the processes that your Custom Object records are a part of. The required properties are the ones circled in the example below:
-
The searchable properties: These are the properties that you can use the CRM search bar for. They’re what shows up in Custom Object views as being filterable by default. These should be properties that help you and your users find records that are otherwise difficult to identify. Here’s what that looks like:
-
The secondary display properties: These are the properties that show up under the Primary Display Property in the Custom Object record summary. They appear with the Primary Display Property in the association cards on the right-hand sidebar when you’re within a single record. They’re also the default column headings for Custom Object views. Check out the examples of this below:
If you avoid these 3 mistakes, you’ll never have to go through the pain of deleting a Custom Object in your Hubspot portal unless there are major changes to your business and its processes. You’ll be well on your way to more effectively tracking key data for your business, as well as customizing your CRM for your business needs.
Of course if you don’t know cURL, Javascript, PHP, Ruby, or another programming language that can work with an API, you’ll either need to find a developer who does or you’ll need a Custom Object builder. Luckily for you, the Lift Custom Object Interface both makes it easy, and has baked-in features that help you be sure you create Custom Objects correctly the first time, every time. After all, you probably want to manage your Custom Objects with a simple, straightforward interface rather than through a myriad of API calls you have to configure yourself. Especially one that helps you avoid mistakes. And unlike a developer, the tool is entirely free.
