Every ServiceNow customer eventually integrates it with other IT systems. The platform is the system of record for service management, and a system of record is only as useful as the data crossing into it. The question is never whether to integrate. It is which integration approach to choose, and the approaches differ far more than you can see at surface level.
This is a comparison of the four most common approaches to ServiceNow integration, judged on what matters once the integrations are live: who is accountable when they break, how they absorb change, how far they reach beyond ServiceNow, and how cost behaves as the estate grows.
Key takeaways
- Every approach in this comparison can connect ServiceNow to the systems around it. They differ in what happens after go-live: who watches the flows, who restores them and who absorbs the next upgrade.
- IntegrationHub is the shortest path inside a ServiceNow-centric estate. On a transaction-metered entitlement, cost rises with volume and retries, so it rises fastest when something is already going wrong.
- A general-purpose iPaaS gives your team the broadest toolkit. The vendor answers for the platform, and your team answers for the integrations.
- ITSM sync tools handle a defined ticket sync well. Every new customer or supplier connection adds another configuration your team maintains, upgrades and answers for when it fails.
- The decisive question is what is at stake for your business when an integration breaks, and which approach brings that risk down far enough for your situation. In most estates it comes down to who restores service when the failure sits between two vendors.
The ServiceNow integration approaches at a glance
- ServiceNow IntegrationHub. Native, fastest to start inside ServiceNow, ServiceNow-centric by design, transaction-priced.
- General-purpose iPaaS (leading vendors in the category). Widest connector coverage and strongest build-time tooling, operated by your team.
- ITSM data sync tools. Purpose-built for ticket and record synchronisation between service management platforms, deployed and maintained by you.
- ONEiO, a Managed Integration Service. Any-to-any connectivity operated as a service: ONEiO runs the integrations, monitors them 24/7 and is accountable under a service level for keeping them running as your connected systems change.
The operating discipline behind option four. The Integration Ops book sets out how the integration lifecycle is planned, run and measured under a Managed Integration Service. Download the book.
What is a ServiceNow integration platform?
A ServiceNow integration platform is any technology and operating arrangement used to move data between ServiceNow and other systems, whether those systems belong to you, to a customer or to a supplier. The term covers connectivity, data mapping, error handling, monitoring and the ongoing change work required as the connected systems evolve. The four approaches below differ mainly on which of those responsibilities you keep.
Option 1: ServiceNow IntegrationHub
IntegrationHub is ServiceNow's native integration capability. ServiceNow describes it as a way to "build reusable integrations with third-party systems and call them from anywhere in the ServiceNow AI Platform", built around pre-packaged spokes and custom integrations (ServiceNow product documentation). If your integration requirement lives inside ServiceNow and the systems you are connecting to have a spoke available, it is the shortest path from requirement to working flow.
Where it fits. ServiceNow-centric estates, internal integrations, teams already fluent in Flow Designer, and requirements that are unlikely to move outside the ServiceNow boundary. Our overview of ServiceNow integrations, Integration Hub and two-way options covers the mechanics.
What to plan for. Integration Hub transactions are not part of a standard ServiceNow subscription and are bought separately. ServiceNow's own contract addendum defines the unit. An Integration Hub Transaction is "any outbound call originating from Integration Hub, Flow Designer, Remote Tables, or Orchestration" (ServiceNow IntegrationHub and Workflow Data Fabric addendum).
Where an entitlement is metered that way, the arithmetic follows the definition. A flow that loops over records makes one outbound call per record, and each retry on a failing action makes another. Volume is highest when the business is busiest, and retries are highest when something is already going wrong.
Check which entitlement you are actually on before modelling this. ServiceNow's packaging in this area has changed, and the same addendum lists newer Workflow Data Fabric SKUs alongside the legacy transaction-metered tiers. The cost question is real on a metered entitlement and largely moot on an inclusive one, so establish which you hold before it becomes an argument with procurement.
The second consideration is architectural. IntegrationHub is built to integrate with ServiceNow. In an estate where ServiceNow is one of several service management platforms, or where the counterparty is a customer running something else entirely, the native option starts doing work it was not designed for. We cover the workarounds in alternative solutions for ServiceNow Integration Hub.
Option 2: a general-purpose iPaaS
Leading iPaaS solutions offer large connector libraries and mature build-time tooling. For an organisation with an internal integration team and a wide estate spanning ERP, CRM, HR and service management, an iPaaS is a rational platform decision.
Where it fits. Organisations with in-house integration capability, a broad estate beyond ITSM, and the appetite to run an integration platform as a discipline. Our iPaaS solution shortlist compares the main platforms.
What to plan for. The vendor commits to platform availability, and published terms bear that out. Boomi's service level agreement, for example, measures availability as the share of a month that its platform and production runtime cloud were available for access (Boomi SLA). Your team commits to everything else: monitoring the flows, responding when one fails, re-mapping when a connected system changes its schema, and re-testing after every upgrade at either end. That work is where most of the lifetime cost sits.
An iPaaS is a good fit for your situation when integrations stay stable after deployment, when little is at stake when one breaks, or when you have the capability in-house to take that responsibility.
Option 3: ITSM data sync tools
Some tools are built specifically for ITSM integrations, and some of them, such as Perspectium, specialise exclusively in the ServiceNow data landscape. These data sync tools typically synchronise tickets, incidents and records between service management platforms, and for a well-defined two-way sync between two known systems they are often the most direct answer.
Where it fits. A defined synchronisation between a small number of known platforms, where the connection scope is stable and the team can maintain it. We compare this category against the others in top ITSM integration tools.
What to plan for. Each of these is a component you deploy and operate. As the number of connected parties grows, you are running an increasing number of configured connections, each with its own upgrade path, its own failure modes and its own maintenance obligation, and your team answers for every one of them when it fails.
Option 4: a Managed Integration Service
A Managed Integration Service takes the platform, the operational management and the accountability. The provider builds the integrations, monitors them continuously, responds to failures under a service level, and absorbs the change work when a connected system is upgraded.
Where it fits. Estates with multiple service management platforms, integrations that cross organisational boundaries into customers or suppliers, high change rates in the connected systems, and a business consequence when a flow stops.
What to plan for. The commercial shape is a subscription, and the comparison to run is that subscription against platform fees plus the fully loaded internal cost of operating the estate. The bigger shift is in what you keep and what is taken care of for you.
What you keep is the integration strategy, the governance, and the knowledge of your own endpoints: what each system holds and what the business needs from it. What is taken care of:
- Building the integrations and running them 24/7.
- Keeping them operational when a connected system goes down, including the maintenance, upgrades, migrations and recovery that takes.
- Meeting the service levels and passing the audits that depend on them.
With ONEiO, each of your systems connects once. ONEiO's any-to-any connectivity handles the differences between endpoints, so you do not add complexity to your own ServiceNow instance or other systems to make an integration work, and adding a customer does not mean another point-to-point build.
"We can trust the interface, and we can trust the team behind." -- Gabriel, Trumpf
Four popular ServiceNow integration approaches compared
How to choose your approach to ServiceNow integrations
Five questions, in the order that resolves the decision fastest.
Is ServiceNow the centre of your estate, or one platform among several? If ServiceNow is the centre and the counterparties are internal, IntegrationHub is the pragmatic answer and the rest of this comparison is academic. If you are connecting several service management platforms, or connecting outward to customers running their own, the native option is working against its design.
Does the integration cross an organisational boundary? Internal integration is a technical dependency. Cross-organisation integration adds a level of complexity and change you do not control, and an escalation path that has to be negotiated. That changes which approaches remain viable.
How often do the connected systems change? Count the last 12 months. In a low-change estate, any of the four work. In a high-change estate, the approaches where your team absorbs every upgrade start consuming the capacity they were bought to free.
What is at stake when a flow breaks? Name the processes that stop, the service levels that keep running against work nobody can see, the invoices that go out wrong and the customers who notice first. If little is at stake, any approach with a working fix process will do. If a broken flow costs revenue, penalties or a renewal, the approach has to bring that risk down, not just restore the connection eventually. Our piece on the true cost of integration failure shows how far that reaches.
Where should accountability realistically sit? Ask whether your team is equipped, staffed and available to keep business damage to a minimum when a flow fails between two vendors, at any hour. The first three approaches answer that the same way, with your team, and that is the reason the fourth exists. If the honest answer is that your team works it out at the time, the recovery clock starts with a negotiation rather than with a fix.
Common ServiceNow integration scenarios to consider before you get started
ServiceNow to Jira. The most common cross-team requirement, and the one where ITSM sync tools compete most directly. The variable is scope: a single two-way ticket sync between two teams is a tool problem, while a service provider synchronising tickets with dozens of customers on different platforms is an estate problem.
ServiceNow to SAP. Typically a service or incident flow tied to a business process with a financial consequence, which raises the accountability question sharply. The integration is rarely the hard part. The change management around a system that is upgraded on somebody else's schedule is.
ServiceNow to Salesforce. Usually a case-and-account flow between service and commercial teams, where the two systems are owned by different parts of the business and evolve independently. Ownership of the interface contract matters more here than connector availability. We walked through a live version of this in creating a ServiceNow, Salesforce and Jira integration.
ServiceNow to a customer's ITSM (eBonding). Ticket exchange across an organisational boundary, with service levels measured against work that arrives through the integration. Native and tool-based options can achieve the connection. What they do not address is who is accountable for the service level when the connection is the thing that failed. Covered in full in ServiceNow eBonding explained, with the alternatives.
Bottom line on ServiceNow integration platforms
All four approaches can connect ServiceNow to the systems around it. Connectivity has not been the differentiator in this category for several years.
Integrations will fail at some point. What separates the approaches is how far each one brings down the business risk when that happens, and the answer depends on your situation: how complex the estate is, how fast the connected systems change, and how well your team is equipped and available when something breaks. Three of the four approaches leave the restore with your team. One puts it in a contract.
Pick the approach that matches where your estate is heading. The ServiceNow-centric answer is correct for a ServiceNow-centric estate, and most service estates stop being one.
Bring your own scenario. Schedule a 30-minute conversation and we will map your ServiceNow integrations against the four approaches with your systems, your change rate and what is at stake for your business.
