When you buy and implement a critical new marketing automation or CRM system, you’ll need to integrate it with your existing systems to maximize the impact across your business. At that point, you (and likely your IT department) will be faced with a very important decision to make:
Should you go with your new system’s native integration capabilities? Or should you go with a third-party integration option such as an integration hub?
As with most quandaries and forks in the road, there are pros and cons to each path you take and decision you make. To help you make that decision between "going native" or "going hub", we’ve broken those advantages and disadvantages down for you here.
Pro for Native: Native integrations are supported by their parent company
Not every parent system will offer or support native integrations. For the ones that do however you will get support from these parent companies. For example, if you ever have an issue with data or triggers or functionality between Salesforce / HubSpot and your other systems, the support and technical reps there should be well-equipped to help you out. Marketo's native CRM integrations are a Marketo SalesForce integration and a Marketo Microsoft Dynamics integration, and HubSpot's native CRM integration is a HubSpot SalesForce integration. (So as an aside if you are integrating Marketo or HubSpot with CRMs such as NetSuite, SugarCRM, Zoho, Vtiger -- the decision likely has already been made for you.)
Pro for Integration Hub: That parent company has many other engineering priorities
The counter-point to the above, however, is that these companies have many, many other engineering priorities as they have core systems that represent the majority of their product development focus. It would be important for you to assess, through questions or scenarios, and understand how much of a priority this specific integration is to the parent company. How often is it updated? How frequently are they enhancing it? Was it done as a one-time effort to address painful customer needs, or is it part of the ongoing strategic development of that product? One way to find out is to talk to other customers who are using this integration and learn if it's evolving to meet their needs. Is it likely this integration is going to get future engineering or support resources vs. the many other priorities that the parent company will need to focus on for their core functionality?
Pro for Native: Native integrations are usually free
Native integrations typically come free of charge, or more specifically they are baked into the total cost of ownership that you pay for purchasing that specific platform such as Marketo, HubSpot or the CRM system. After signing an expensive contract, many companies will find the free price of the native integration more appealing than paying for third-party integrations.
Pro for Integration Hub: Native integrations lack depth -- and what if that means your specific use case or custom objects aren't well supported?
The counterpoint to free is that free often comes with hidden costs. Is it free because it lacks the depth or support that you get from other paid options?
The best software companies - Salesforce and HubSpot included - have a strong sense of focus, and they specific things really well. Unfortunately, this can also create a bit of tunnel vision about how they expect people to use their software and integrations. When Salesforce developed their native integration, their engineers were thinking of from their perspective, rather than holistically. What compromises were made so that the native integration could be affordably built and offered for free? And what happens when those compromises limit your integration capabilities?
If you have unique ways with which you’re using your Salesforce or HubSpot systems - say, for instance, with many custom fields and objects - these native integrations aren’t going to go far enough in terms of letting users customize or tailor the integration. If your business records sales, marketing and customer data in a different way, you should consider expanding beyond the capabilities of the system’s native integration.
Pro for Native: Native integrations are ready to use out of the box
No need for custom engineering. Furthermore, native integrations are highly contextual to its native system. If you don’t have complicated sales and marketing operations processes or a great deal of custom objects, the native integration will likely meet your immediate point-to-point integration needs.
Pro for Integration Hub: What if you have three or more systems (and you probably do...)?
Let’s take subscription billing company Zuora as an example. Salesforce and HubSpot integrate seamlessly with each other, and Zuora works well with Salesforce’s native integration. Unfortunately, neither HubSpot nor Zuora have a native integration for each other. A company using all three systems will find that relying solely on point-to-point native integrations paints an incomplete, disconnected picture of that company’s data; there wouldn’t be an easy way to get Zuora information into HubSpot, and vice versa.
Point-to-point native integrations may "band-aid" a specific short term requirement, but they won't scale as you'd like to tie in more and more systems such as billing, support, e-commerce, webinars or events to name a few.
And therein lies another issue with native integrations; data silos. You already know that data silos are bad for your business, segregating important data and impeding open collaboration. Native integrations can help you solve your data silo issue between two functions (for instance, sales and marketing) but if the other parts of the company - and their systems - aren’t also being integrated, you’ve just created another silo. Until all your systems across all functions are integrated, something very hard to do with just native integrations, you won’t be able to truly bring down those dreaded data silos.
If you’re a large company with many systems and you find yourself constantly putting out integration fires on many different fronts, then the native integration isn’t going to work.
Pro for Integration Hub: Native integrations may force you to dedicate engineering resources to build out your business requirements -- and then who will maintain those customizations?
There is likely to come a point in time when the native integrations in Salesforce or HubSpot are not enough to work with your other systems. At that point, you’ll have to write custom code, and engineering will inevitably have to be pulled in.
Take it from us: dedicating engineering resources to work on integrations - at the expense of working on your company’s own product - is not a good use of time or resources. This is a poor allocation that arose because you thought your native integrations would be sufficient, when they weren’t. Don’t make that mistake.
Not to mention if you are fortunate enough to get the engineering support to get the APIs to work well for you, are you going to get the committment from your engineering team that they will both support and evolve those APIs as your requirements inevitably change? That answer will probably be "no".
There are several other questions you should ask your system vendor and your own internal IT team - is the native integration bidirectional? How often does it automatically sync data? How many custom objects are you working with? - to keep in consideration, along with the aforementioned characteristics. This is a good start for you though to determine the pros and cons of native integrations vs. an integration hub, and which path is the right one for you.