In the world of ServiceNow, seamless integration is key to achieving operational efficiency and driving digital transformation.
However, as ServiceNow offers many integration possibilities with third-party systems, this article aims to guide you through the labyrinth of available integration choices, focusing on maintaining a lean and scalable platform primed for future development. We will investigate when and why specific integration patterns are recommended over others.
By the end of this article, you will have a comprehensive understanding of choosing the best integration approach for connecting ServiceNow to a third-party system.
ServiceNow Integration Pattern Decision Tree
Please note: This article covers product capabilities as of the Yokohama (March 2025) release that are generally available for all commercial customers. Please contact your Account Team if you have any entitlement or subscription questions.
The ServiceNow Integration Decision Tree below is a flowchart that guides you through choosing the best integration pattern for connecting to a 3rd party system. Here’s how to read it:
- Start at the Top and Follow the Arrows: Each arrow leads you from one decision to the next.
- Answer the Questions: The blue boxes contain questions you need to answer about your specific integration needs. Depending on your answers, you will follow the corresponding arrow to the next step.
- Reach an Outcome: The round boxes represent integration patterns. These are the recommended integration patterns based on your answers to the previous questions. The color coding represents the overall alignment to integration best practices. If you end up with a pattern marked orange or red, you may want to revisit your decisions to see if a better pattern is within the realm of possibility.
You may also want to refer to the Now Create: Integrations Workshop Presentation to learn more about ServiceNow integration design.
The key decision points have been marked with a blue circle and a letter and will be explained below.
[A] Persist data in ServiceNow
Remote tables are essential when data persistence is not an option. Remote tables allow real-time access to external data without storing it in ServiceNow. There are two reasons why you may not want to store data in ServiceNow:
- Very high Data Volume: For extremely large or frequently changing datasets, storing data in ServiceNow may not be feasible. Remote tables ensure access without compromising performance.
- Legal and Compliance Constraints: Some data must remain within specific boundaries due to legal constraints. Remote tables enable compliance by allowing interaction without violating regulations.
[B] Usage of an ESB or Integration Middleware
One popular approach is leveraging an Enterprise Service Bus (ESB) or middleware to facilitate system-to-system integration. ESBs provide a unified platform for connecting diverse applications, allowing seamless data flow and communication across systems. While discussing the advantages and disadvantages of such an approach would qualify for a whitepaper on its own, there are a few considerations to keep in mind:
- Most ServiceNow Plugins, Store Apps, and Integration Hub Spoke are designed to work with the API structure and behavior of the respective 3rd party tool. If the middleware solution does not mirror this API fully, extensive customization is required, which increases complexity, delays implementation, and raises the total cost of ownership for the integration.
- Any middleware adds additional points of failure regarding system stability and security.
- Some ITOM Solutions, such as Discovery, Service Mapping, and Orchestration, do not work without a MID Server.
[C] ServiceNow Instance Integration Options
There are four recommended options when an integration between two ServiceNow instances is desired:
Service Bridge:
Service Bridge provides capabilities targeted to telecommunication and technology industries for providers supporting their consumers, partners collaborating with providers, and inter-service operations. It is designed explicitly for Telco/Tech/MSP, where one instance represents the customer and one instance the provider. However, it has limited flexibility for data synchronization and requires agreement between the parties regarding the integration approach.
Instance Data Replication (IDR):
IDR copies data updates from one instance to one or more others, maintaining consistent data across different ServiceNow instances. It supports unidirectional and bidirectional replication and allows for limited data modification during replication. This solution is ideal for real-time replication of large data sets. However, IDR can only sync reference fields if IDR also synchronizes the target table of the reference. It is limited to 3 million records per replication set. For a complete list of limitations, please refer to the documentation.
Remote Process Sync (RPS):
RSP enables one-way or bidirectional integrations between instances to keep processes in sync. With RPS, you design flows on both instances using Flow Designer and synchronize them. It is ideal for real-time task-based process replication, ensuring message order execution despite connectivity issues. However, it requires separate creation and planning for each integration, which may be excessive for simple use cases.
Remote Instance Spoke:
This is a set of out-of-the-box actions for creating ad hoc integrations between instances. It is simple for ad hoc integrations but is not recommended for heavy integration use, as all flow logic, security, and error handling need to be implemented.
If none of these options fit your requirements, please follow the decision tree to explore other data transfer capabilities, such as Integration Hub Import.
[D] Using an OOTB Solution
Wherever possible, an Out-of-the-box approach shall be used. There are three patterns to distinguish between:
Native Integration (ServiceNow Plugin or Store App):
For some third-party applications, ServiceNow provides native connectors as well; for example, HR comes with a SuccessFactors integration. These are usually ready-made and require only a few configurations, so they should be used if applicable.
Integration Hub Spokes:
Integration Hub enables the execution of third-party APIs as part of a Flow when a specific event occurs in ServiceNow. These integrations, referred to as Spokes, are easy to configure and enable you to quickly add powerful actions without writing a script. However, more effort is usually required compared to the “ready-made” integrations mentioned above.
Extending an existing Spoke using Spoke Generator
If the use case only partially matches an existing Spoke, extending the existing Spoke using the Spoke Generator is still better. This can be done by either importing an OpenAPI specification or using Now Assist with the third-party API documentation snippet as input. This simplifies the integration process compared to starting from scratch but still provides flexibility to accommodate specific requirements.
ServiceNow Technology Partner Store App:
ServiceNow Technology partners provide ready-to-use Integration solutions via the ServiceNow Store. Check on the ServiceNow store to see whether an integration product is already offered to serve your needs.
[E] Event-driven architecture (EDA)
Event-driven architecture (EDA) is a design pattern that enables systems to communicate and react to events in real-time. By decoupling the producers and consumers of events, EDA can improve your applications' scalability, performance, and reliability. Usually, this is an existing or even mandated architecture principle organization-wide. Stream Connect lets you connect your ServiceNow instance to your existing Kafka environment and stream data bidirectionally between them.
The first step is to determine the direction of the data flow relative to ServiceNow:
- Producing Data: ServiceNow needs to send data to Kafka.
- Consuming Data: ServiceNow needs to receive data from Kafka.
When ServiceNow needs to push data out to a Kafka topic, consider the nature and volume of the data: For log and audit data, there is a pre-built capability. To stream any other data from ServiceNow to Kafka, using the Scriptable ProducerV2 API in a Business Rules provides better performance, whereas the Kafka Producer Action Step is easier to setup and maintain.
When ServiceNow needs to ingest data from a Kafka topic, the primary consideration is what you intend to do with the incoming data: Flows can be triggered via the Kafka Message trigger, whereas data can be transformed with either Transform Maps or ETL, depending on the target. Similar to Scripted REST API, a Script Consumer can be used to address any other use cases.
[F]&[G] Initiating system and Pull vs Push
Two key concepts regarding ServiceNow integrations are the initiating system and the direction of data flow (pull vs push). Understanding these concepts is essential for designing and implementing effective integrations.
Initiating System:
The initiating system starts or triggers the integration process. Depending on the use case and chosen integration method, it can be either ServiceNow or a third-party system.
For instance, if ServiceNow needs to fetch data from an external database, ServiceNow acts as the initiating system. Conversely, if a third-party system needs to create a ticket in ServiceNow, the third-party system becomes the initiating system.
Pull vs. Push:
The terms ‘pull’ and ‘push’ refer to the direction of data flow between the systems.
A ‘pull’ integration occurs when ServiceNow retrieves or ‘pulls’ data from a third-party system. An example is when ServiceNow uses a REST API to fetch foundation data from an external system and store it in a ServiceNow table.
On the other hand, a ‘push’ integration happens when ServiceNow sends or ‘pushes’ data to a third-party system. For example, if ServiceNow, acting as the initiating system, replicates ticket data into a data warehouse, it’s a push integration.
There are pros and cons to having ServiceNow take control over an integration, e.g., pulling foundation data into the platform, compared to just waiting for the following data load to be pushed in by the other system at an inconvenient time.
The best possible combination of these two patterns depends on various factors, such as the frequency, volume, and complexity of the data exchange, the security and performance requirements, and the availability and capabilities of the 3rd-party system. You should establish a platform-wide guideline to ensure a consistent approach is followed by everyone building integrations for your organization.
[H] Process (REST) APIs
ServiceNow offers process-specific APIs for some use cases (e.g., Service Catalog or Change Management).
As the Process APIs require data to be in a specific format, it is impossible to transform it. Additionally, the Process API may skip certain validations (which you could implement in a Transform Map or RTE), which may have a negative impact on your process. Therefore, please confirm on a use-case-per-use-case basis if the Process API is a good match.
[I] Choice of Web Service Protocol
Different web service protocols can be used when integrating ServiceNow with external systems. However, not all protocols are equally suitable for every scenario. The following guidelines can help you choose the best protocol for your integration needs:
REST:
This is the most recommended protocol for ServiceNow integration. It is widely adopted in the industry, easy to use, and offers great low-code and debugging capabilities in the platform. REST uses JSON as the data format, which is lightweight and flexible.
GraphQL:
This newer protocol allows clients to specify the data they need from the server, reducing the amount of data transferred and improving performance. GraphQL can be used with ServiceNow through a custom GraphQL schema, but it requires more development and testing effort than REST.
SOAP:
This older protocol uses XML as the data format, which is more complex and verbose than JSON. SOAP should be avoided unless a specific requirement or legacy system only supports SOAP.
Open Database Connectivity (ODBC):
This protocol allows direct access to the ServiceNow database through an ODBC driver. This should only be considered a last-resort fallback, as it requires more maintenance and troubleshooting than web service protocols.
[J] Table API vs. Scripted REST API
When granting read access via REST or SOAP to data in ServiceNow, two choices are available:
Standard Web Service (Table API):
This predefined API does not require further configuration, allowing for out-of-the-box integration capabilities for most platform tables.
Scripted REST/SOAP API:
This is a custom API that developers can script according to specific requirements. It offers more flexibility but requires more effort to set up and maintain.
The aim should always be for systems to retrieve data from ServiceNow in the original structure and move potential transformation into the responsibility of the 3rd-party system. If this is not possible, the preferred method would be a Scripted REST API calling a Subflow, as this is primarily low-code. It involves creating a subflow containing the API's logic and calling this Subflow from the Scripted REST API. This approach reduces the required scripting and makes the API easier to maintain.
[K] UI-level Integrations
When the need arises to display ServiceNow data or processes within the user interface (UI) of a different application, the ServiceNow platform offers several distinct capabilities.
For Customer Service use cases, verify first if Engagement Messenger covers your use case, as this is a ready-to-use integration capability that just needs to be plugged into an existing web site.
If the objective is to embed ServiceNow functionality or display ServiceNow data directly within an existing native mobile application (iOS or Android), the Mobile SDK is the appropriate choice. It provides the tools and libraries necessary for developers to build ServiceNow integrations into their mobile apps.
If none of the specific UI integration capabilities are applicable, you need to consider other integration methods like APIs or web services, depending on the specifics.
[L] Fallback Solutions
File-based integrations, robotic process automation (RPA), and email are available methods of integrating ServiceNow with other systems. However, these methods have some limitations and drawbacks, such as:
- File-based integrations require manual or scheduled data transfers, which can be slow, error-prone, and insecure.
- RPA relies on mimicking user actions on the user interface, which can be brittle, inefficient, and hard to maintain compared to a web service.
- While Email is a simple and widely used communication channel, it has limited capabilities for structured data exchange and processing and limited scalability.
Therefore, these three approaches should only be treated as fallback technologies for ServiceNow integrations. Whenever possible, ServiceNow integrations should use more robust and reliable methods, such as the options described on the left side of the decision tree.
Acknowledgments
I would like to thank the following people for providing feedback and improvement suggestions:
-
Bruno De Graeve, ServiceNow
-
David Skowronek, ServiceNow
Changelog
Version 3.0: Yokohama April 2025
- Added a dedicated section for event-driven architecture
- Added a dedicated section for UI integrations
- Added the following capabilities
- Flow Designer Action JDBC step
- JDBC Data Source
- Document Intelligence
- External Content Connectors for AI Search
- HR Multi Instance Integration
- MetricBase Time Series API
- Reworked Table API recommendation to include security requirements
- Updated ERP Canvas to reflect name change
Version 2.0: January 2025
- Reworked decision on data persistence requirements
- Clarified options for integration patterns between 2 ServiceNow instances
- Added ERP Data Hub
- Added Generative AI Controller
- Added Process Mining for External Data
- Added Performance Analytics with external data
- Added remark to Spoke Generator
19 Comments
