ServiceNow integrations: keep the process working when the systems underneath it change.
New to us? If the real question is which system should own which record, start with Business Process Consulting and Design.
Your process shouldn't stop at a platform boundary. It often does.
Your order moves from sales to finance to fulfillment. Your service case depends on the invoice and the installed base. Each of those handoffs is an integration, and many were built for one project by someone who has since moved on. We start from which system owns each record. Then we choose the pattern, design the failure path and document it so your team can run it.
One team solves a problem, another solves it again months later, and nobody can see what already exists.
Two systems disagree about the same customer, and there is no documented answer for which one wins.
A process stops on Sunday and someone notices on Wednesday. Then both sides argue about who owns the fix.
Credentials expire, source schemas change, and nobody is watching.
None of this is an engineering failure. Three decisions were never written down: which system owns the record, what happens when it changes, and who answers when it stops.
One offer. The technology that fits the handoff.
ServiceNow Integrations is our offer. The platform underneath gives us a full range of integration technologies, from code-heavy to no-code, from real-time to batch, from moving data to leaving it where it is. We pick the right one for each handoff in your process.
When the process needs precise control or the external system has a proprietary API, we build on the protocol directly. Custom REST or SOAP steps, scripted where the logic requires it. This is still where most custom integration work lives.
Prebuilt action bundles for external systems, configurable and maintained by ServiceNow or a partner. Where a spoke covers the process, we use it. Where it doesn't, we build a custom action or extend what's there.
Not every record needs to move. Zero Copy Connectors query data at the source so the workflow can see it without copying it in. Fewer sync problems, no stale duplicates.
Stream Connect for high-volume event pipelines, RPA Hub for systems with no usable API, Data Products for governed data reuse, MCP connectors for AI agents. Each solves a specific kind of handoff.
All of this sits inside Workflow Data Fabric, ServiceNow's umbrella for connecting the platform to everything else. The breadth is real. The design work is choosing which technology fits each handoff: its direction, its timing, its failure behavior, and who owns the data.
Ownership first. Then the interface.
Which system owns each record is a business decision. We make it with you in Business Process Consulting and Design, per object and in writing. This page starts where that decision ends. If it hasn't been made yet, start there. An interface built on an open ownership question carries the disagreement into production.
With ownership settled, we specify every interface the same way: one row per object, covering direction, pattern, frequency, failure behavior and owner. Each interface also gets a criticality rating and a last-validated date, so it stays operable after go-live.
Related: Business Process Consulting and Design.
Choose the pattern that fits the process.
- 01Does the workflow read, or does it write?
- 02How urgent is it really?
- 03How much volume is there, now and in three years?
- 04What should happen when the other system is down?
- 05Who transforms the data on the way through?
Real time often sounds better than it needs to be. We ask what actually breaks if the data is an hour old.
The workflow needs an answer before it can continue.
Your process now depends on the other system being available.
Something happened, and another system needs to know.
Ordering and duplicate events become your problem. For high-volume event platforms, Stream Connect handles the pipeline.
Volume is high and same-day is good enough.
Data is as fresh as the last run. Usually cheaper and more predictable, and dismissed too early.
One business event has to reach a defined end state across several systems.
Every step needs a designed failure path.
The system has no usable interface and won't be replaced this year.
It breaks when the screen changes, so it needs its own monitoring. Not elegant, and right more often than architects admit.
You need a MID Server when the target sits inside your network or the integration uses database, scripting or shell access. It runs in your network and holds credentials for the systems it reaches, so plan it as a component with an owner.
Enterprise API management, business-to-business file exchange and high-volume middleware are good reasons to keep what you have. We'll connect ServiceNow to it rather than rebuild it on Integration Hub. Where Workflow Data Fabric is the better answer, we'll say so.
Not sure where your integration boundary should sit?
Find out before you build it.
Standard integrations are a starting point, not the finished process.
ServiceNow ships a broad set of standardized integration options: prebuilt spokes for major systems, certified connectors and ready-made protocol steps. Coverage grows with every release.
The Salesforce spoke covers seven objects: Account, Contact, Case, Lead, Opportunity, Order and User. SAP integration is split across ten spokes. A spoke gives you reach into an external system. It doesn't give you the field mapping, the process design or the failure handling. Those are still the project.
Reads through a zero copy connection. You map the columns, write no code, and get read-only access. It suits warehouses, lakes and databases such as Snowflake, Databricks or Oracle.
Runs a script or flow you write against a REST or SOAP source, including another ServiceNow instance. It can cache results for up to an hour. With insert, update and delete scripts, it can also write back to the source. Agents see it in lists and forms, and developers query it with GlideRecord, like any other table. The price is code you own.
An agent who only ever looks at an order from the ERP doesn't need a nightly import that copies it. That import adds storage, a schedule and a reconciliation problem. So we choose by what the process does with the record: move it, read it, or change it at the source.
We bring the detailed knowledge to make that call. For the most common integration scenarios, we work from proven blueprints that cover your requirements. Where a spoke doesn't cover the process, we build the missing actions and package them as a custom spoke. A spoke you keep working around costs more than a custom action designed on purpose.
Low-code reduces the effort. It doesn't remove the engineering where interfaces are proprietary, data models are complex or a legacy system has a poor API.
Three design decisions keep an integration working.
A retry against an interface that isn't idempotent creates a second posting. So we make every write idempotent before anything can retry it.
For each step, we decide: wait, retry, carry on, or stop and escalate. Flow error handlers catch the failure, but someone still has to decide what they do. Decide nothing and the process stops silently. The same applies to a remote table: someone has to decide what the agent sees when the source doesn't answer.
By default, ServiceNow generates flow execution details only when you run a test. ServiceNow recommends enabling detailed reporting only on non-production instances, to avoid performance issues. So production monitoring has to be designed: error handlers that log the failure and alert the owner named in the interface specification.
Commercial and technical things to check first.
Integration Hub usage is metered in transactions against a subscription. A product can ship with spokes and still not include the transactions to run them. Those may need an Integration Hub or Workflow Data Fabric subscription at an additional fee. We estimate volume during design, not at renewal.
ServiceNow requires an Integration Hub entitlement for any remote table that reads from a source outside the platform.
Polling the same system, moving data nobody uses and duplicating interfaces all consume transactions. Caching, reusing a data product and triggering only on change keep the count down.
Integration Hub and Zero Copy Connectors are requested from ServiceNow, not switched on by you. Build that lead time into week one.
Primary connectors are built and supported by ServiceNow. Community connectors aren't maintained or supported by ServiceNow, which advises against using them in production. Minimum release also differs per connector. So we confirm connector type, minimum release and support path for every source in the first workshop.
Zero Copy Connectors don't support it. Integration Hub does. Remote tables don't separate their rows natively, but the script behind them can enforce domains through the DomainSupport API. That is code you write and test, not a setting. For a group running several legal entities on one instance, this decides which patterns are available. We raise it in week one, not after contract signature.
A remote table returns 1,000 rows by default. Any filtering and sorting the script doesn't handle runs on the instance after the fetch, and that gets slow on large result sets. Query design belongs in the specification, not in the first performance ticket.
With a data fabric table, records stay in the source. ServiceNow stores the table definition and holds records in memory, read-only, when they're queried. A remote table works the same way, with two differences. Its script can cache results in memory for up to an hour, per user by default. And if write-back is enabled, changes go to the source through your scripts. Zero Copy Connector for ERP is the exception, because it can mirror data onto your instance.
Data fabric tables and remote tables use ordinary table access controls. Data products add a request-and-approve step, with separate roles for connecting sources, stewarding data and consuming it. Someone has to hold each role.
Yes. Reverse Tunnel connects Zero Copy Connectors to private and on-premises sources. It is infrastructure in your network that needs an owner, not a setting. Integration Hub uses a MID Server for the same job. A remote table reaches on-premises sources through whatever its script or flow calls, typically a MID Server.
Keeping records at the source is a property of zero copy, not a guarantee for the whole platform. We check where each AI feature processes data before anyone assumes it stays in place.
An agent that acts in another system is an integration with an unpredictable caller.
ServiceNow AI agents act through defined tools. A subflow is one such tool. MCP connectors in Connect Hub let agents reach external systems directly. So everything on this page still applies.
Give the agent explicit actions, not broad access.
Make each action idempotent before an agent can call it, because an agent retrying a non-idempotent action creates duplicate postings very quickly.
Reachable isn't the same as trustworthy. If two systems disagree about who the customer is, an agent connected to both just disagrees faster.
Related: ServiceNow AI · AI Control Tower.
An interface with no business event behind it is a pipe somebody will inherit. A data product with no workflow consuming it is a catalog entry nobody opens.
Scoped from the source system outward, data programs get large. Scoped from the workflow inward, they get smaller.
Where it doesn't, we build on purpose instead of working around it.
Zero copy for one, event-driven for another, batch for a third, all in the same process. That's a sign the design fits.
Transaction volume and entitlement shape the pattern we choose, so you know the running cost before build instead of finding out at renewal.
Our practice is the commercial, customer and project side of ServiceNow. The interface is designed for a process we already work in.
Sometimes the fix is a data quality problem to solve before connecting anything. Sometimes it's the middleware you already run.
Senior practitioners design your interfaces and stay through delivery.
Related: Customer Service Management · Sales CRM · CPQ · Field Service Management · Strategic Portfolio Management.
Find out where your integration boundary should sit before you build it.
Most integration estates were not designed. They accumulated, one project at a time, and each addition was reasonable. Start with how the process actually runs today. If the honest answer is a data-ownership problem to settle first, we will say that too.
- Workflow Data Fabric
- ServiceNow's umbrella for connecting the platform to other systems and data. It includes Integration Hub, Zero Copy Connectors, Stream Connect and Data Products.
- Integration Hub
- The part of Workflow Data Fabric that makes things happen in other systems, through spokes and custom actions. Its transactions aren't included in a subscription product.
- Spoke
- A bundle of ready-made actions for one external system, built by ServiceNow or a partner.
- Zero copy
- Data is queried where it lives rather than copied in. Check the product, though: Zero Copy Connector for ERP can mirror data onto your instance.
- Data fabric table
- External data shown inside ServiceNow as if it were local. Read-only.
- Data interface
- A stable schema between a data source and the workflows that use it.
- Data product
- One or more data interfaces with an owner and access control, published for reuse.
- MID Server
- An application running inside your network so ServiceNow can reach systems that aren't reachable from the internet.
- System of record
- The one system whose version of a record is treated as correct when systems disagree. Decided per object, in Business Process Consulting and Design.
- Idempotency
- Designing an action so that repeating it doesn't duplicate the result.
The questions buyers ask us.
How does ServiceNow integrate with other systems?
›
Through Workflow Data Fabric, ServiceNow's umbrella for connecting the platform to everything else. Integration Hub makes things happen in other systems, using prebuilt spokes or custom actions. Zero Copy Connectors show external data without copying it. Stream Connect handles high-volume events, import sets handle file and database loads, and RPA Hub drives systems with no usable interface. MCP connectors let AI agents reach external tools. A MID Server or Reverse Tunnel reaches systems inside your network.
What is ServiceNow Integration Hub?
›
The part of Workflow Data Fabric for building reusable integrations with other systems and calling them from any flow. Without it, Workflow Studio automates only inside your own instance. Some subscription products include spokes, but Integration Hub transactions are never included. Those need an Integration Hub or Workflow Data Fabric subscription.
What's the difference between Integration Hub and Workflow Data Fabric?
›
Workflow Data Fabric is the umbrella, and Integration Hub is one part of it. The real contrast is inside Workflow Data Fabric. Integration Hub acts in another system. Zero Copy Connectors let a workflow see another system's data without copying it. We deliver both under one offer, ServiceNow Integrations.
What does zero copy mean in ServiceNow?
›
The data is queried at the source instead of copied in. With a data fabric table, ServiceNow stores the table definition and metadata and holds records in memory, read-only, when they're queried. One exception matters: Zero Copy Connector for ERP can read, create and update data in SAP, SuccessFactors and Workday, and it can mirror ERP data onto your instance. Check which product you're using before you assess the risk.
Can ServiceNow integrate with SAP?
›
Yes, in three ways:
- Integration Hub spokes. ServiceNow documents ten SAP spokes, split by product and protocol (IDoc, RFC, OData), all built by Bristlecone. Several need a MID Server.
- Zero Copy Connectors. SAP ECC and SAP S/4HANA are primary zero copy connectors, which give read-only access.
- Zero Copy Connector for ERP. Reads and writes SAP data.
Each covers entity-level operations, not a whole business process. The process design is still the project.
Do we need a MID Server?
›
Only if the target sits inside your network, or the integration uses database, scripting or shell access. Cloud-hosted targets with an accessible API usually don't need one. Zero Copy Connectors use Reverse Tunnel for the same job. Either way, it's infrastructure in your network, so plan it as a component with an owner.
Should we use a prebuilt spoke or build a custom integration?
›
Use the spoke where it covers the process, and check that it does. The Salesforce spoke, for example, covers seven objects. Where the spoke doesn't cover the process, custom actions on Integration Hub's protocol steps fill the gap, packaged as a custom spoke if several flows reuse them. A spoke you keep working around costs more than a custom action designed on purpose.
What happens when a ServiceNow integration fails?
›
That depends on whether the failure path was designed. ServiceNow provides retry policies and flow error handlers. By default, though, execution details are generated only for test runs, and ServiceNow warns that detailed reporting in production can hurt performance. So production monitoring has to be designed: idempotent actions, a decision for when the other system is down, and alerts to a named owner. After go-live, Solution Support also covers failures that start in a connected system.
How much does a ServiceNow integration cost to run?
›
There are two costs. The build is scoped like any development work. The running cost is Integration Hub transactions, which aren't included in a subscription product, even one that ships with spokes. Estimate volume during design, and track it on the Integration Hub Usage Dashboard, rather than finding out at renewal.
Can Workflow Data Fabric connect to our data warehouse?
›
Probably. Snowflake, Databricks, Google BigQuery, Amazon Redshift, Microsoft OneLake and Teradata are among the primary connectors, built and supported by ServiceNow. Community connectors cover more sources, but ServiceNow doesn't support them and advises against production use. Minimum release differs per connector, so we check it for each of your sources.
Does it work with domain separation?
›
Partly. Integration Hub supports domain separation. Zero Copy Connectors don't. For a group running several legal entities on one instance, that limits which patterns are available, so we check it in the first workshop.