Welcome to this HubSpot Academy podcast on a hot topic in our agency partner community.
Here, your host, Adi Shah, Partner Professor at HubSpot Academy, interviews HubSpot Solution Architect Mike Hodsdon on six solutions for creating custom objects in HubSpot.
Here's the full audio of the podcast:
Prefer to read? No problem! Check out the transcript of the entire episode below:
Introductions and background [00:00]:
Aditya Shah: Alright, I'm excited to have all of you here, partners! We're going to be talking today with Mike Hodsdon, who's a solution architect on HubSpot’s sales engineering team. We're going to be talking about custom objects today, and for those of you asking for more material on CRM migrations, integrations, and many topics related to that, I think this will be a very interesting video. I'm Adi Shah. I'm the partner professor on HubSpot Academy. I feel like you hear from me quite a bit. Mike, tell us a little bit about what a solution architect does.
Mike Hodsdon: Yes, so a solution architect at HubSpot is a technical resource that works on larger CRM migration, implementation, integration type opportunities before the sale closes. So, we work alongside the account exec, alongside the partners, alongside the sales manager, and we're pretty much the technical voice that answers some of the more interesting technical questions that will come up during an [00:01:00] evaluation of enterprise CRM.
Mike Hodsdon: And honestly one of the reasons that I got into this space in general is that I really like finding native ways of bringing technology and humans together. And when we're talking about custom objects, it's a very interesting problem because we're getting into, really, kind of the nitty-gritty details of how humans interact with data in the system. Sorry about that [message from Slack].
Aditya Shah: No worries at all. This is a workday. We're [00:01:30] having this conversation in the middle, and so we'll get pings and all kinds of noises coming out of Slack. They (our listeners) know how it is! I think a bunch of our partners use it too, so, yeah.
Mike Hodsdon: Gotcha. So basically, in recap, a solution architect is there to kind of answer those deeper questions about how does technology interact with humans, but also how do we get data where it needs to go? How do we store it? How do we surface it within CRM? How do we then act on it and then report on it? So those are really the main things that I focus on.
Can HubSpot handle custom objects? [02:05]:
Aditya Shah: That's awesome. And I think it's going to be very interesting for HubSpot with this particular role in this focus on upmarket CRM implementation for complex organizations to the partner program. I've been talking about it at lunch, we're going to talk about that in the future. But for today's topic, I wanted to kind of start with the elephant in the room, which is this perception that HubSpot cannot technically handle [00:02:30] custom objects yet. There's some truth to that, but I don't think people get the full story. And so, Mike, if you could dive right into us and tell us like what do you think about that question and how people should answer it?
Mike Hodsdon: Yeah, so when I get the question of can HubSpot can handle custom objects, it really depends upon the context how I answer it, to be completely candid. In a lot of cases we're talking to a marketer, so we're talking to someone less technical [00:03:00] and other times we're talking to a database administrator who really understands deeply data structure and models and has worked with an enterprise CRM or data architecture before. So, in the truest sense of the word, can we spin up a totally custom object in HubSpot? In a lot of cases, we actually can use some of the methods that we're going to discuss because a lot of times businesses ultimately want to take that data and be able to act on it with automation. [00:03:30] They want to be able to maintain a one-to-many relationship between contacts and events that are occurring in their world.
Mike Hodsdon: So, really understanding the business context of how they're asking the question and who we're talking to will kind of influence how I answer it. But in the truest sense of the word, it really is: "We can, we can solve a lot of custom data problems within the HubSpot platform." And if we're talking to somebody who has a custom named object [00:04:00] in another CRM and that's really, they're tied, they're hung up on the naming convention of it. Maybe not the naming aspect of it, but from a data perspective, we can store a lot of that data within our platform, and we can take actions on it. So it's definitely not a straight yes or no answer, but in most cases we can actually accommodate folks and what they'd like to do with the custom object in HubSpot.
Aditya Shah: That's really interesting and I really like how you bring it back [00:04:30] to the business problem. Like why do they need the custom object in the first place because that really determines what kind of solution you are going to prescribe for them.
Overview of concrete ways to address the custom objects challenge in HubSpot [04:45]:
Aditya Shah: And so in this particular case, there are a couple of methods that stand out that we were discussing earlier. You talked about using CRM extensions, using the Timeline API, using analytics events, and even repurposing existing HubSpot objects. And I was wondering if you could [00:05:00] dive into those a little bit and talk about, like, you know, what are the differences between each of those methods and, like, when you'd recommend them?
Mike Hodsdon: Yeah, for sure. So we kind of mentioned this before, but really I break it down into four main categories of things that people like to do with custom objects. And the first is they want a place to store data, right? So they need a place to put it. Then they need to be able to surface it to users of the software in different ways. [00:05:30] And then, really, it's a question of can those users manipulate it or do they just need to view it? But that whole surfacing conversation of, like, "What's any user to do with the data?" is kind of the second main component.
Mike Hodsdon: The third component is automation. So, can we automate and do things within the CRM, within the marketing automation platform based on the data? And what would they like to have happen when these objects are created? And then the last piece is reporting, how would [00:06:00] they like to report on it? So, with all of those things, kind of in context, those four buckets, the Timeline API is honestly my go-to method for solving most custom object type of conversations. The reason I say that is most of the time our customers really do want to have visibility in the CRM that something has happened relative to a contact or a company, and then they want to be able to automate on that.
Aditya Shah: Right.
Concrete example of why the Timeline API is a great solution [00:06:30]:
Mike Hodsdon: So just to kind of use a concrete example, if we're talking to a recruiting firm, so they cultivate two separate pipelines of folks they're talking to — companies that they'd like to get business to place, like find hires for jobs, and then they're talking to job applicants, right? In the job applicant case, a contact in this case or an applicant can be applying to multiple jobs at one time with that recruiter. And so they often want to treat that [00:07:00] application as a custom object, right?
Aditya Shah: Right.
Mike Hodsdon: In that instance, the Timeline API is actually a really great way of solving for this because they usually want to automate some type of follow-up when someone has applied for a job, which we can, and they want to be able to see the characteristics of the jobs that people are applying for.
Aditya Shah: Right.
Mike Hodsdon: Or be able to build a list of contacts that have applied to jobs of a particular type in the last three months. So [00:07:30] in those cases, the Timeline API, when you're looking to push an event in and see details about it and be able to segment and then act on it, it's a really good solution for them. And that's kind of the reason why I discuss it first in the list.
Aditya Shah: Interesting, interesting. And that makes sense to me as, like, being a go-to method because of the advantages you've described. But if we look at some of the other methods that are out there like CRM extensions [00:08:00] and even using events, analytics events, like what, how would you compare and contrast the advantages of those methods? Like what makes them different in terms of reporting, in terms of other variables to consider?
Mike Hodsdon: Yup. So the one main drawback of using the Timeline API is that there's no inherent ability to report within the reports functionality, the dashboard functionality of HubSpot. You can map events to contact properties and have them push [00:08:30] into object properties as they come in. But it doesn't really give you that true one-to-many reporting that you would look for sometimes when you're looking to build a report based upon the number of folks that have taken this action or applied to those jobs, right. We can segment on it in the lists tool, but we can't report on it within the reporting engine directly and really break it down.
Mike Hodsdon: So an interesting couple of other options on the table. We talked about analytics events. [00:09:00] Analytics events are basically a very simple yes or no. An event happened a number of times. How many times did it happen, what time did it happen? And really just yes or no. So if people need to know has a contact taken an action relative to their business and they just need to know yes or no, the number of times that it happened, but they don't need to know properties about it, events can be a relatively quick way to spin that up.
Mike Hodsdon: And [00:09:30] a caveat with all of these things— you're usually talking about a custom integration to get them built out, right? So we're able to spin up events within the UI [inaudible 00:09:41], but then setting them and getting them to happen relative to an object is going to happen through the API.
Aditya Shah: Right, right. But then you can report on them, right? Like, there's some reporting available in HubSpot using HubSpot's reporting tools, like event funnels, et cetera. And so you'd say that's [00:10:00] a big difference between the Timeline API and analytics events, right?
Mike Hodsdon: Yep. Yeah. You can spin up as many different kinds of events, like as many different types of actions that people can take. And then you can report on how those events are happening in your system, in your HubSpot portal. CRM Extensions is basically another way that you can get visibility into this, into another system from within HubSpot.
Mike Hodsdon: So, if we're transitioning to that conversation, [00:10:30] this is when someone really wants to be able to surface the data within the CRM but they don't need to store it, they don't need to segment on it, and they don't need to report on it directly.
Aditya Shah: Right. Because it's not actually being stored in HubSpot, it's just coming in from the external system, right?
Mike Hodsdon: Correct, so, but you're able to surface, so, we're talking to prospects that have an external system that may have a dashboard for an account, right, that has the account health, that has some other things that they're tracking in their ERP for example. [00:11:00] That's a good instance where you might actually use a CRM extension to surface a card within the CRM that gives the rep a window into that world, into that ERP data world, without actually leaving HubSpot.
Aditya Shah: I see.
Mike Hodsdon: And that's the true value there. You want your users to be able to get that 360 degree view of what's happening with your contacts and with your accounts without actually leaving the tool. That's what CRM Extensions really does. The caveat [00:11:30] there being you can't do the storage segmentation or reporting.
Aditya Shah: Right, I mean, like you said, it depends on what kind of custom object people need and what business problem they're solving. I can see CRM extensions and have seen CRM extensions be perfectly useful for certain kinds of situations like sales reps who just need to see data. Sometimes renewal managers need contract information. They don't necessarily need to do anything with it, they just need to be able to see it for context. So that makes a lot of sense. [00:12:00] And you know we're going to have more information in the blog post that I'll be releasing shortly in which Mike and Isaac Takushi from our developer advocate team share their insight on this custom object question.
Aditya Shah: We also got a couple of questions from social media as well, from LinkedIn and from Facebook, and so I wanted to go ahead and ask those here. Phil Vallender, who is the director and co-founder at Blend Marketing, had a question. He said, [00:12:30] "The challenge is when custom objects are in established use where the data isn't replicated in other systems and the relationships with contacts or companies are many-to-one or many-to-many. Do you have any tried and tested strategies for flattening this kind of data and suitable migration paths and that would be most helpful?"
Mike Hodsdon: Yeah, for sure. So, the other thing that we haven't really talked about, I guess there are two solutions that we haven't dug into. One is taking that relationship [00:13:00] and flattening it and by flattening what we mean is we're going to take the fact that a contact can apply to multiple job opportunities, but we're going to create a job opportunity set of custom properties that sit on that contact record, and then we're going to push data into those properties, and they will change over time. And through segmentation you can actually go back and say like, "Have they ever, has the value of this property ever been X, Y, Z?" So we have some visibility into the history [00:13:30] there, but you're really only seeing the most recent instance of that custom object related to the contact [crosstalk 00:13:39] for any contact property. So we're really taking that one-to-many relationship and flattening it down into one instance of that object. That can be a great solution for folks if they just need to quickly spin up filters for deal view, like has a contact ever had this attribute? [00:14:00] If we're looking to look at really just kind of making that, taking that data and making it actionable in HubSpot, that can be a good solution.
Mike Hodsdon: The other thing that will come up here is leveraging the existing relationships between contacts, deals, tickets, and companies in HubSpot. And we do have the ability to do many-to-many in custom deal and ticket pipelines, and leveraging that one-to-many relationship between [00:14:30] contacts and deals, contacts and tickets, and then the many-to-many relationship between deals and tickets to start to build up those more complex relationships that some of our customers' data sets have.
Mike Hodsdon: The main caveat there is they do need to be comfortable with these objects still being called companies, contacts, deals, and tickets. You can rename the pipelines within deals and tickets to be whatever those objects are representing, whether it's subscriptions, [00:15:00] whether it's applications, whatever they're calling it in their nomenclature, you can have that be the pipeline for that object, and the benefit there is we actually can go forward, and we have full manipulation of the data on those objects. We have full storage, data, full segmentation and reporting as well. So to kind of answer Phil's question, you really want to be looking at that many-to-many between deals and tickets and seeing if there's an opportunity to map [00:15:30] their existing structure into that. And with the caveat that they're still going to have to click on the deals and the tickets tabs within the software. Right, But ultimately when they get there they'll have a pipeline that reflects the name of their existing object.
Aditya Shah: No, that makes a lot of sense. I mean a number of customers that even I've seen, for example, they have invoices they need to track separately, and they have information coming in from, let's say, Sage. So then they have like a separate pipeline for those invoices and it's perfect. [00:16:00] Then they can report on that revenue in a clean way. And so that makes a lot of sense. And you know, flattening it out into properties is also some variation of leveraging existing features within HubSpot to solve the cross-object question. So that's a great question Phil. Thanks for that. We had another question as well. This time from Facebook, from Amanda Daume. I apologize if I'm mispronouncing it. My name gets mispronounced all the time. I'll learn it over time.
Aditya Shah: [00:16:30] And Amanda was asking, she's curious about how we can better configure custom timeline events to be more user-friendly in workflow and list criteria. And I think this is a good question because you were saying that it depends on what you intend to do with this custom object. So if you could talk a little bit more about that.
Mike Hodsdon: Yeah, my entire mentality towards this whole question is really understanding what needs to be in HubSpot versus what they'd like to have in HubSpot and [00:17:00] keeping it as simple as possible. Because, while you can do a lot of customization here, really what it comes down to is you want a marketer or a sales user or someone to be able to go into the lists tool and quickly understand the different types of buckets that they can put their contacts into.
Mike Hodsdon: Right? And so, I'm sure some of you guys have seen some of the integrations that you plug into HubSpot. When you go down the left-hand side of the lists screen, they will have multiple [00:17:30] timeline event types associated with the integration. So timeline, you're basically installing that integration into the portal and then it's creating these different events, the timeline event types that will live inside of the segmentation tool within lists. So, really to answer the question directly, you have control over which of those event types you create for your integration, how many you create for your integration, and then ultimately the layer below that is you can create [00:18:00] properties related to each event type. And you can have those. So in the example of applicants, if you wanted to break out separate segmentations for accountants that are applying versus engineers that are applying, you could have separate lines within the segmentation criteria, one being accounting type segmentation, the other being engineering, and you would have two separate [00:18:30] buttons there that you can click into and then see the properties.
Mike Hodsdon: The other way of doing it is keeping that list of options and segmentation shorter at the top level and just saying, okay, we're actually just going to have an applicant type or an industry or a job name or description that is just a property within it. So in a way you're flattening it down to just having properties under one event type. That's a way that you can simplify the user interface a little bit. [00:19:00] Again, you have trade-offs because each event type, will have as many properties as you put underneath it, so you don't want to be scrolling for days in the properties, so you want to kind of walk that balance between organizing it in a way that makes sense in different buckets for each event type and simplifying the number of event types that you have.
Aditya Shah: Yeah, I mean the user experience is important too. If you intend this to be useful to sales reps or to consultants then they shouldn't be overwhelmed trying to find the data they're [00:19:30] looking for. So that's a very valid point. We have to think about the user experience when designing these as well.
Aditya Shah: This has been very, very helpful, Mike. I think this is going to answer a lot of questions that partners have on this topic. And so, you know, now the answer isn't just a flat-out no. When this question is asked, it's a more nuanced answer that considers the business problem that the custom object in question is solving and then gives a nuanced solution, which in many cases solves the problem that our customers or clients for our partners [00:20:00] may have. So thanks so much for taking this time to speak to us, for taking this time out of the middle of your day in the week before INBOUND. We're looking forward to meeting with you. Both of us are HubSpotters, we're going to be at INBOUND. Let us know if you have any further questions or comments on what we discussed here today, and we'll see you around.
Want to connect with others on HubSpot tips, tricks, and updates? Head over to the HubSpot Community to join a conversation or start one of your own.
