From the Eng Org: How we built Custom Objects for Salesforce and Hubspot (so you don’t have to)

Supporting custom objects in a Unified API was not an easy build. But it was absolutely worth it to support our customers’ need for customized data models.

To accompany Merge’s launch of Custom Objects for Salesforce, Hubspot, and Zendesk Sell, we sat down with two key players on the project: Prannoiy Chandran, CRM API Platform Lead, and Joshua Learn, Expansion Engineer, to hear first-hand what it took to go from initial spec to launch-ready build. 

If you’re looking to add support for custom objects to your own product — we hope to make the process of adding scalable support a tiny bit smoother.

‍Merge: Let’s start with this: how did custom objects make it to the roadmap?

Prannoiy Chandran (PC): Even when scoping our CRM API [launched in Q2 2022], we knew custom objects were a key part of any CRM system. Still, we wanted to gather data points on how our customers wanted to use them, before committing to any feature-specific build: we knew custom objects were not going to be easy.

By Q4 of 2022, we had enough context on the capabilities our customers wanted, and we could respond by scoping out a feature-set that would enable users to read, write, and update custom objects from their customers’ CRMs. ‍

Merge: You mentioned customer use cases, can you give us context on what things companies are trying to build with custom objects?

‍PC: Absolutely. Custom objects are super flexible by nature, but we really saw use cases pop up everywhere, such as representing a product’s data — or really, their unique value — directly in a CRM. Additionally, being able to pull in custom objects related to key CRM models was critical: it would allow users to do things like build up complex reports and analysis on sales data. This is all super important stuff when you’re offering CRM integrations to your customers. 

Merge: You mentioned custom objects ‘were not going to be easy,’ why is that?

‍Joshua Learn (JL):  Most CRMs store the same type of data: Leads, Opportunities, etc. So for normal, standard types of objects, ‘non-custom’ objects, they are represented pretty uniformly, even in different APIs.

When it comes to Custom Objects, it suddenly becomes very difficult to unify. 

I’ll explain. You have to not only express the actual data being stored inside the CRM; you also have to be able to express the schema, the types of things that it can hold, the types of things that it can be related to, and you have to generalize that in a way that unifies across all those different CRMs. 

All the while, you’re going to need to provide capabilities that actually take into account everything that all of these different CRMs are capable of: such as GET, POST, or PATCH support.

Custom Objects, as it appears in Merge’s guide

Custom Objects, as it appears in Merge docs

PC: Going off of that unification challenge — today, for example, we launched with Custom Objects support for Salesforce, HubSpot, and Zendesk Sell. They've really been the focus of this whole project.

But one critical need early on was to prove out a valid unified approach that we could extrapolate to other integrations. 

Our initial feature set included four data models that fit the majority of use cases we were seeing:

• Custom Object records
• Custom Object classes
• Associations 
• Association types

It would also allow us to scale to many integrations.

‍Merge: Focusing on the engineering side, could you tell us about how you decided on those features? 

‍JL: That was design spec’ing: You figured out what your customers want, now you need to design a customer-facing feature set, like a customer-facing API, and what types of information they might want to know or troubleshoot via dashboard.

‍These things get really complicated, but you don't want it to be too complicated for anyone to use, or they're not going to use it.

We also needed to spec the actual implementation on our side:

• How we're actually going to achieve this in our backend infrastructure
• How we’re going to store the data models
• How someone would interact with them 
• How we’d surface them via our API

There are all sorts of challenges with this. When you have something that's a completely arbitrary structure, that you only know the shape of once your customers are using it, you have to be able to handle a very flexible schema. 

Engineering spec’ing is also a great challenge: how are we going to achieve what we put in the customer facing spec?

‍Merge: So you’ve spec’d the specs — what was the build like?

‍JL: It was a continual pair programming back and forth between me and Prannoiy. 

I was working from the backend infrastructure point of view, figuring out how we're actually implementing, how we're going to handle it in a way that is broadly applicable to all of the different APIs and integrations Merge wants to build out for customers and users. 

Prannoiy was more on the customer facing side and actually building out the support per integration, doing the research on the integrations: what they offer, and what they support. 

Then it involved a lot of testing and validating with our initial customers to make sure we got things right. 

‍Merge: Even now that the feature is launched, do you consider the work finished?

JL: Of course not. We want to continue to support this feature, address edge cases as they come up, make sure any issues are resolved, and expand support to more integrations.

‍Merge: And tell us — what’s on the roadmap for the future?

‍PC: Merge Custom Objects currently supports Salesforce, HubSpot, and Zendesk Sell. On the short term roadmap, we’ll be supporting ActiveCampaign, Zoho CRM, and Microsoft Dynamics, and looking into further developing future iterations of Merge Custom Objects. 

We’ve currently just built out the API aspect of it. We have thought about the visual aspect, in terms of adding it to the dashboards. If we get more demand for it, we can get more data points and can strategize on how we are going to design it, and what kind of use cases it may serve. 

This is a pretty complex situation to try to normalize. We've made some decisions here, as to how to do it, but we set it up in a way that leaves the door open to adding a lot more functionality.

‍Merge: Any closing thoughts?

‍JL: We’re extremely excited to see what people build.

If you want to learn more about Merge Custom Objects, please reach out to our team to discuss how we can support your use case.

If you're a Merge customer on the Professional and Enterprise plans, you'll be able to use Custom Objects right away.

‍