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. Use these pros and cons of native integrations to help you make that decision between "going native" or "going hub" when adding a new marketing automation or CRM system to your tech stack.
Pro: Native integrations are supported by their parent company.
Many parent systems will offer or support native integrations. For example, if you ever have an issue with data, triggers, or functionality between Salesforce or HubSpot and your other systems, the support and technical reps there should be well-equipped to help you out.
Marketo's native CRM integrations include a Marketo SalesForce integration and a Marketo Microsoft Dynamics integration, and HubSpot's native CRM integration is a HubSpot SalesForce integration. If you are integrating Marketo or HubSpot with CRMs such as NetSuite, SugarCRM, Zoho, Vtiger, you will likely need to invest in an integration hub.
Con: 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. 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?
It is important to assess 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 a specific customer need, or is it part of the ongoing strategic development of that product? One way to find out answers to these questions is by talking to other customers who are using this integration and asking if it's evolving to meet their needs.
Pro: 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 a 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.
Con: Free can mean a lack of depth and flexibility.
The best software companies have a strong sense of focus, and they do 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 a native integration is developed, engineers are often thinking 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 systems like Salesforce or HubSpot - say, for instance, with many custom fields and objects - native integrations aren’t going to go far enough in terms of letting you 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.
Read Next: 7 Things to Consider Before Buying Software
Pro: Native integrations are ready to use out of the box.
There's no need for custom engineering with native integrations. Furthermore, they are highly contextual to their native system.
If you don’t have complicated sales and marketing operations processes or a great deal of custom objects, native integrations will likely meet your immediate point-to-point integration needs.
Con: You can not easily integrate multiple systems.
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's not 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.
Con: Native integrations can create more 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: Native integrations often require zero code.
If you have a limited IT department or a time-strapped engineering team, using a native integration may be the best fit. Native integrations can be up and running quickly, since they require no code and are generally fairly simple to set up. Many parent companies also offer helpful walkthroughs and support articles that provide all the details needed to get the integration working with your systems.
Con: At some point, you may need to dedicate engineering resources to build an integration that fits your business requirements.
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. 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 commitment from your engineering team that they will both support and evolve those APIs as your requirements inevitably change?
Take it from us: dedicating engineering resources to work on internal integrations - at the expense of working on your company’s own products or services - is not a good use of time or resources. If a native integration is no longer fulfilling your company's needs, look into an integration hub instead of pouring hours and possibly thousands of dollars into building your own customer integration.
In Conclusion
There are several other questions you should ask your system vendor and your own internal IT team before choosing between a native integration and an integration hub. Is the native integration bi-directional? 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.
