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 capability as of the Washington DC (March 2024) release._

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:

1. **Start at the Top and** **Follow the Arrows**: Each arrow leads you from one decision to the next.
2. **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.
3. **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](https://nowlearning.servicenow.com/nowcreate/en/pages/assets?id=nc%5Fasset&asset%5Fid=85b250e2db3450d077c0ce46b99619d3) to learn more about ServiceNow integration design.

The key decision points have been marked with a blue circle and a number and will be explained below.

## 1: 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.
* There are some ITOM Solutions that do not work without a MID Server, e.g., Discovery and Service Mapping, as well as Orchestration.

## 2: 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 a 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. More effort is usually required compared to the “ready-made” integrations mentioned above.

**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.

## 3: Event-driven architecture (EDA)

Event-Driven Architecture (EDA) is a design pattern that enables systems to communicate and react to events in real-time. EDA can improve your applications' scalability, performance, and reliability by decoupling the producers and consumers of events. Usually, this is an organization-wide existing or even mandated architecture principle. Stream Connect lets you connect your ServiceNow instance to your existing Kafka environment and stream data bidirectionally between them.

## 4&5: 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 is the one that starts or triggers the integration process. Depending on the use case and chosen integration method, it can be either ServiceNow or the 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.

## 6: 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.

## 7: 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, as 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.

## 8: 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 tables in the platform.

**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 mostly 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.

## 9: 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.

---

#### Page 2

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 capability as of the Washington DC (March 2024) release._

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:

1. **Start at the Top and** **Follow the Arrows**: Each arrow leads you from one decision to the next.
2. **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.
3. **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](https://nowlearning.servicenow.com/nowcreate/en/pages/assets?id=nc%5Fasset&asset%5Fid=85b250e2db3450d077c0ce46b99619d3) to learn more about ServiceNow integration design.

The key decision points have been marked with a blue circle and a number and will be explained below.

## 1: 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.
* There are some ITOM Solutions that do not work without a MID Server, e.g., Discovery and Service Mapping, as well as Orchestration.

## 2: 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 a 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. More effort is usually required compared to the “ready-made” integrations mentioned above.

**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.

## 3: Event-driven architecture (EDA)

Event-Driven Architecture (EDA) is a design pattern that enables systems to communicate and react to events in real-time. EDA can improve your applications' scalability, performance, and reliability by decoupling the producers and consumers of events. Usually, this is an organization-wide existing or even mandated architecture principle. Stream Connect lets you connect your ServiceNow instance to your existing Kafka environment and stream data bidirectionally between them.

## 4&5: 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 is the one that starts or triggers the integration process. Depending on the use case and chosen integration method, it can be either ServiceNow or the 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.

## 6: 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.

## 7: 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, as 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.

## 8: 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 tables in the platform.

**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 mostly 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.

## 9: 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.