Every ServiceNow implementation eventually faces a critical integration design decision: which pattern to use when connecting the platform to external systems. ServiceNow offers dozens of integration patterns, from Integration Hub Spokes to Zero Copy Connectors to AI Agent protocols. Choosing the wrong one may lead to months of rework. This guide helps you choose the right one.
The Integration Pattern Decision Tree walks you through each decision point, explains the tradeoffs between competing options, and gives you a defensible rationale for the pattern you select. It covers web service integrations, copyless data access, event-driven architecture, AI agent connectivity, UI-level embedding, and fallback approaches when APIs are missing.
ServiceNow Integration Pattern Decision Tree
This article covers integration patterns built on or fully native to the Now Platform architecture, reflecting product capabilities as of the Australia (April 2026) release that are generally available for all commercial customers. ServiceNow's portfolio also includes products with independent technology stacks and their own integration ecosystems. Please consult the respective product documentation for integration guidance outside the Now Platform scope. Please contact your Account Team if you have any questions about your entitlements or subscriptions.
The ServiceNow Integration Decision Tree below is a flowchart that guides you in choosing the best integration pattern for connecting to a third-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 with 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 available.
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.
Table of Content
- [A] Web Service Integrations
- [A1] Usage of an ESB or Integration Middleware
- [A2] ServiceNow Instance Integration Options
- [A3] Using an OOTB Solution
- [A4] & [A5] Initiating system and Pull vs Push
- [A6] Process (REST) APIs
- [A7] Choice of Web Service Protocol
- [A8] Read Operations: Table API vs. Scripted REST
- [A9] Write Operations: Choosing the Right Inbound Pattern
- [B] Copyless Data Access
- [C] Event-driven architecture (EDA)
- [D] AI Agents
- [E] UI-level Integrations
- [F] Fallback Solutions
- Acknowledgments
- Changelog
[A] Web Service Integrations
Web services are the preferred method for system integrations, mainly because of their widespread industry adoption and proven interoperability standards. Their inherent flexibility allows organizations to connect disparate platforms efficiently, adapting to various use cases and evolving business requirements.
[A1] Usage of an ESB or Integration Middleware
One popular approach is leveraging middleware to facilitate system-to-system integration. While discussing the advantages and disadvantages of such an approach would qualify for a whitepaper on its own, it is important to distinguish between the two most common categories and understand the key tradeoffs.
An Enterprise Service Bus (ESB) or Message Bus is a centralized hub that coordinates communication across enterprise applications. ESBs handle message routing, data format and protocol transformation, orchestration of multi-step processes, and asynchronous message delivery. They are typically found in organizations with diverse legacy systems using different protocols and data formats.
An API Gateway is a proxy layer focused on managing, securing, and monitoring API traffic. It handles authentication, rate limiting, and request routing for systems that already communicate via REST/HTTP. While the line between the two is blurring, especially with certain iPaaS platforms, the core difference remains: an ESB transforms and orchestrates between heterogeneous systems, whereas an API Gateway manages access to systems that already speak a common API language.
Both categories share the same tradeoffs when placed between ServiceNow and a third-party system:
|
Pros |
Cons |
|
|
As a general rule, prefer direct integration unless organizational architecture mandates middleware or centralized governance is critical. In practice, the vast majority of ServiceNow integrations work better as direct connections. Middleware adds value primarily when 3+ systems need the same data transformation or when regulatory audit requirements mandate a single control point.
Most ServiceNow Plugins, Store Apps, and Integration Hub Spokes are designed to work with the native API of the respective third-party tool. If the middleware does not fully mirror this API, extensive customization is required, which increases complexity, delays implementation, and raises total cost of ownership. Furthermore, ITOM solutions such as Discovery, Service Mapping, and Orchestration require a MID Server and do not work through middleware.
[A2] ServiceNow Instance Integration Options
There are five recommended options when an integration between two ServiceNow instances is desired:
Service Exchange (formerly Service Bridge)
Service Exchange provides capabilities targeted at the telecommunication and technology industries for providers supporting their consumers, partners collaborating with providers, and inter-service operations. Designed for Telco/Tech/MSP scenarios, Service Exchange suits situations where Instance A is a provider fulfilling requests from Instance B’s users, like a shared IT services firm managing incidents for multiple clients.
|
Pros |
Cons |
|
|
There is an HR-specific Service Exchange called HR Multi Instance Integration (HR MII), enabling cross-instance HR service communication. It centralizes HR Service Delivery in a shared model, letting providers publish record producers that employees request from their instances. Requests sync to the provider where HR cases are created.
Instance Data Replication (IDR)
IDR copies data updates from one instance to one or more others, maintaining consistent data across ServiceNow instances. It supports unidirectional and bidirectional replication with limited data modification during transfer. Ideal for real-time replication of large data sets. Reference fields can only sync if IDR also synchronizes the target table. For a complete list of limitations, please refer to the documentation.
|
Pros |
Cons |
|
|
Remote Process Sync (RPS)
RPS 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.
|
Pros |
Cons |
|
|
Remote Instance Spoke
This is a set of out-of-the-box actions for creating simple 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.
|
Pros |
Cons |
|
|
ServiceNow Remote Instance Zero Copy Connector
The Zero Copy Connector enables read-only access to data in a remote ServiceNow instance without copying or replicating it. Data remains in the source instance and is queried on demand via dedicated ZCC tables. Ideal for reporting, cross-instance visibility, and analytics without impacting the source environment. When process sync, data persistence or bi-directional communication is required, IDR or RPS are the better options.
|
Pros |
Cons |
|
|
In summary:
- Provider/consumer workflows ⇨ Service Exchange
- Bulk data replication ⇨ Instance Data Replication
- Real-time process sync ⇨ Remote Process Sync
- Quick ad hoc integration ⇨ Remote Instance Spoke
- Read-only cross-instance reporting ⇨ Zero Copy Connector
If none of these options fit your requirements, please follow the decision tree to explore other data transfer capabilities, such as Integration Hub Import.
[A3] Using an OOTB Solution
Wherever possible, an Out-of-the-box approach should 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 than creating a Spoke from scratch. This can be done by either importing an OpenAPI specification or using Now Assist in Integration Hub with the third-party API documentation 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.
To find a matching solution, search the ServiceNow Store (store.servicenow.com) by the third-party product name. Also, check the Integration Hub Spoke library in your instance under Flow Designer > Spokes to see what is already installed or available.
[A4] & [A5] Initiating system and Pull vs Push
Two concepts shape every integration design: which system initiates the exchange, and whether data is pulled or pushed.
The initiating system is whichever side triggers the integration process. This can be ServiceNow or the third-party, depending on the use case. For example, ServiceNow initiates when it fetches user records from an HR system on a schedule. The third party initiates when a monitoring tool creates an incident in ServiceNow.
Pull means the initiating system retrieves data from the other side. Push means it sends data to the other side.
The matrix below shows how these two dimensions combine:
|
|
Initiating System: ServiceNow |
Initiating System: Third-Party |
|
Pull |
ServiceNow fetches external data
Example: |
Third-party queries ServiceNow data
Example: |
|
Push |
ServiceNow sends data outbound
Example: |
Third-party writes into ServiceNow
Example: |
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 third-party system. You should establish a platform-wide guideline to ensure a consistent approach is followed by everyone building integrations for your organization.
[A6] Process (REST) APIs
ServiceNow offers process-specific APIs that encapsulate business logic for specific workflows. The most commonly used Process APIs include:
- Service Catalog API: submits catalog requests with variables and approval flows. Best when external systems need to raise standardized service requests.
- Change Management API: creates and manages change records through their lifecycle. Best when the external system needs to follow the full change workflow including risk assessment and CAB processing.
- Identification and Reconciliation API (CMDB Import API): inserts or updates CIs with identification and reconciliation logic. Best when importing CI data that needs deduplication and relationship handling.
Process APIs add value when you need the built-in business logic they provide, such as catalog item variable handling or CMDB identification rules, that would otherwise require significant custom development.
However, Process APIs come with important limitations:
- They require data in a specific format and do not support data transformation. Unlike the Import Set API, where a Transform Map lets you run scripts to map, validate, and enrich incoming data, Process APIs expect the data to arrive ready to process. This means any transformation, enrichment, or field mapping must happen on the sending side.
- Process APIs cannot resolve reference fields by e.g. display value. They always require the ServiceNow sys_id. For example, you cannot pass an assignment group name; you must pass the sys_id of the assignment group record. This shifts the burden of reference resolution to the calling system, which either needs to maintain a mapping or perform a prior lookup via the Table API.
- Certain logic that you would normally implement via scripting in a Transform Map or Extract Transform Load (ETL) definition, such as conditional field population, cross-table validation, or duplicate detection, will not execute when records are created through a Process API. This can lead to data quality issues if the API is used for a use case that relies on these checks.
Therefore, confirm on a use-case-by-use-case basis whether the Process API's built-in logic justifies these tradeoffs, or whether the Import Set API with a Transform Map gives you the control you need.
[A7] 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. While there are valid use cases for GraphQL in web development, it’s very rarely for ServiceNow implementations that GraphQL provides tangible benefits over a normal REST approach.
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. Additionally, only read access is supported.
[A8] Read Operations: Table API vs. Scripted REST
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, enabling out-of-the-box integration with 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 default should be for external systems to retrieve data from ServiceNow in its original structure and handle any transformation on their side. This keeps the ServiceNow API surface simple and avoids the need to maintain custom response logic for every consumer.
When that is not feasible, for example because the consuming system cannot perform the required transformation or because multiple consumers need the same shaped response, a Scripted REST API calling a Subflow is the preferred alternative. This keeps the transformation logic primarily low code and easier to maintain than a fully scripted API.
[A9] Write Operations: Choosing the Right Inbound Pattern
When a third party needs to create or update data in ServiceNow, the first question is whether the operation imports data into a table or interacts with a process.
Importing Data: The Import Set API is the recommended approach. It supports both REST and SOAP, works with Transform Maps for field mapping and data transformation, and provides built in traceability through import set run records and transform logs. If data needs to be written into more than one target table from a single payload, use the Import Set API with Robust Import Set Transformers.
Interacting with a Process: The communication protocol determines the pattern. When REST is available and the third party can process the ServiceNow data structure directly, the Table API is technically an option. When it cannot, use a Scripted REST API for synchronous use cases or a Flow with REST API Trigger for asynchronous processing.
The same applies to SOAP. If the third party can process the ServiceNow data structure, SOAP Direct Web Services provide basic CRUD per table. If it cannot, a Scripted SOAP Web Service allows full control over the inbound payload but should be treated as a fallback given SOAP's higher complexity and the platform's direction toward REST.
Why direct table writes are discouraged:
Both the Table API and SOAP Direct Web Services allow writing directly into ServiceNow tables without a staging layer. While this is the fastest path to a working integration, it means no Transform Map to absorb schema changes, no import log to trace what was written, and no way to inspect or reprocess failed records. When the source system changes its payload, the integration breaks silently instead of failing visibly at the transform layer. Treat direct table writes as a last resort for process interactions and never use them for data imports.
[B] Copyless Data Access
For most integrations, persisting data in ServiceNow is the right default. Local data enables reporting, workflows, access control, and audit trails without runtime dependency on the source system. It also ensures that ServiceNow processes continue to function when the external system is unavailable or slow.
That said, there are scenarios where persisting external data inside ServiceNow is not the right choice:
- Very high data volume or change velocity: For extremely large or frequently changing datasets, storing data in ServiceNow may not be feasible. Querying data at its source ensures access without compromising platform performance.
- Legal or compliance constraints: Some data must remain within specific boundaries due to regulations. Querying it in place allows interaction without violating data residency requirements.
- Avoiding data duplication and staleness: Maintaining copies of data introduces synchronization overhead and the risk of stale records. Reading data directly from the source system in real time, without persisting it, ensures you always work with the current state.
[B1] Existing Table Requirement
The first question is whether the data needs to be written to an existing baseline table, such as cmdb_ci, incident, or another ServiceNow table. If populating records in an existing table, zero copy approaches are not possible. Zero Copy Connectors and Remote Tables create their own virtual tables and can't insert or update existing tables.
[B2] Zero Copy Access to ServiceNow Data
If the data lives in a ServiceNow instance, the SQL API enables direct, read-only SQL access to data stored in a ServiceNow instance. This is particularly useful for analytics, reporting, and BI tool connectivity where you need to run complex queries against ServiceNow data. The SQL API provides a standard SQL interface, making it straightforward to connect tools like Tableau, Power BI, or custom applications directly to ServiceNow data.
Please be aware that SQL API requires RaptorDB Pro to be enabled on the source instance.
[B3] Data Sources supported by Zero Copy Connectors
Zero Copy Connectors allow retrieving data from third-party systems into Data Fabric tables. These tables can then be used to support business workflows. Like Remote Tables, Zero Copy Connectors cannot populate data in an existing table.
There are two types of connectors available:
- ServiceNow develops and supports primary connectors, with enhancements to improve Glide queries and list views, enabling most queries to run at the data source.
- Community connectors are created by the open-source community and provided by ServiceNow. They are certified for core functions but not supported by ServiceNow.
Currently supported source systems and database types are listed on docs.
[B4] Remote Tables
When the system is not supported by Zero Copy, but offers a web service, then Remote Tables are an alternative. Remote Tables also allow write operations to change data in the source system. However, as they are significantly more complex to set up and maintain, and realistically only process a few hundred records, they should be considered a less favorable choice.
[C] Event-driven architecture (EDA)
Event-driven architecture is a design pattern where systems communicate by producing and consuming events in real time, rather than through direct request-response calls. By decoupling producers and consumers, EDA improves scalability and resilience, as neither side needs to know about or wait for the other. In most organizations, EDA is not a choice made per integration but an existing or mandated architecture principle applied organization-wide.
ServiceNow connects to event-driven environments through Stream Connect, which provides bidirectional streaming between a ServiceNow instance and an existing Apache Kafka environment. Stream Connect is not a general purpose message broker integration. It is purpose built for Kafka.
If your organization uses a different messaging system, you will need to route through Kafka or use a web service pattern instead.
[C1] Direction of data flow
The first step is to determine the direction of the data flow relative to ServiceNow:
Consuming data means ServiceNow needs to receive and process events that an external system has published to a Kafka topic. This is the more common pattern, as organizations often want ServiceNow to react to events occurring elsewhere, such as infrastructure alerts, HR system changes, or order status updates.
Producing data means ServiceNow needs to publish events to a Kafka topic for external systems to subscribe to. This is typical when downstream systems need to react to changes in ServiceNow, such as incident state transitions, CMDB updates, or audit events.
[C2] Consuming external data
When ServiceNow ingests data from a Kafka topic, the right pattern depends on what needs to happen with the incoming data.
If the incoming event should trigger a workflow, use a Flow with a Kafka Message trigger. This is the low-code option and works well when the event maps cleanly to a process, such as creating an incident from an alert or updating a record from an HR event.
If the incoming data needs to be staged, transformed, and written into a single ServiceNow table, use a Transform Map Consumer. This follows the same logic as inbound web service data imports: the data lands in a staging table and a Transform Map handles field mapping, reference resolution, and data quality checks before writing to the target. This is the right choice when the Kafka payload structure differs from the target table.
Also, like web services integration, if data from Kafka needs to populate more than one table, an Extract Transform Load (ETL) Consumer allows you to write data to multiple tables at once.
For use cases that fall outside these patterns, a Script Consumer provides full scripting flexibility, similar to a Scripted REST API on the web service side. It handles the raw Kafka message and lets you implement whatever processing logic is needed. Treat it as the fallback when the low-code options do not fit.
[C3] Streaming ServiceNow data
When ServiceNow needs to push data out to a Kafka topic, the pattern depends on the nature of the data.
For log and audit data, the Log Export Service is a pre-built capability that streams system logs, audit records, and similar operational data to Kafka without custom development.
For any other data, two options are available. The Kafka Producer Action Step in Flow Designer is the low-code option: easier to set up and maintain, and suitable for moderate volumes where ease of configuration matters more than raw throughput. The Scriptable ProducerV2 API called from a Business Rule offers better performance for high-volume or latency-sensitive scenarios, but requires scripting and is harder to maintain. As a general rule, start with the Action Step and move to the scripted approach only if you hit performance limits.
[D] AI Agents
Please note: AI Agent integrations are an emerging capability area. Organizations should evaluate their AI readiness (LLM governance, prompt management, testing frameworks) before adopting agentic integration patterns for production workloads. Start with deterministic patterns (REST, Spokes) and introduce agentic patterns incrementally for use cases where flexibility genuinely outweighs predictability.
AI Agents in ServiceNow automate, personalize support, and improve decisions. Due to their non-deterministic nature, they need flexible, adaptive integrations instead of rigid, rule-based ones.
Five integration patterns are available. Three are AI Agents themselves (Agentic Spokes, A2A, Agentic Desktop / Web Agents) and two are capabilities added as tools to an AI Agent (REST/Web Services, MCP).
Agentic Integration Patterns
Agentic Spokes
Pre-built agent integrations for third-party systems. Best when an out-of-the-box solution exists for the target system. Now Assist for Spokes provides pre-built AI agents for Integration Hub.
|
Pros |
Cons |
|
|
A2A (Agent-to-Agent)
Multi-agent coordination across platforms, exchanging plans and results. Best when workflows require agent collaboration across systems, with each agent acting as an autonomous peer.
|
Pros |
Cons |
|
|
Agentic Desktop & Web Agents
AI-driven UI automation for systems without APIs. Agentic Desktop handles Windows desktop applications, Web Agent handles browser-based systems. Both are goal-oriented and more resilient to UI changes than scripted RPA, but slower than API-based patterns and harder to audit for compliance. These should be treated as a last resort when no programmatic interface is available.
|
Pros |
Cons |
|
|
REST/Web Services (as AI Agent Tool)
Standard web service APIs added as tools to an AI Agent. Best for regulated workflows or business critical processes where predictability and auditability are required.
|
Pros |
Cons |
|
|
MCP (Model Context Protocol, as AI Agent Tool)
Dynamic tool discovery and runtime capability extension for AI Agents. Best when a single agent needs flexibility and the ability to discover tools at runtime rather than working with a static API definition.
|
Pros |
Cons |
|
|
[D1] Deterministic Behavior Requirement
Start by determining if deterministic behavior is needed, such as for compliance or auditing. RESTful APIs are best for reliable, predictable, and auditable integrations. MCP supports flexible tool discovery but introduces variability, making it less suitable for critical or regulated workflows. For those scenarios, choose REST for consistency and reliability. As an example, if an external agent always needs to create a risk record with the same five fields, a standard REST API call is simpler, faster, and more auditable than having the agent discover the risk table schema via MCP at runtime.
For external workflows: if deterministic behavior is required and the external agent can process a static ServiceNow Web Service, use a standard Web Service approach (REST API). If the external agent cannot process a static Web Service, the requirements are incompatible.
For ServiceNow workflows: if deterministic behavior is required, the third-party system must provide a Web Service. If deterministic behavior is not required, consider whether runtime discovery or flexibility actually benefits the process. Unnecessary flexibility introduces risk without adding value.
[D2] Collaboration Model (MCP vs A2A)
The core distinction is scope. MCP (Model Context Protocol) standardizes how a single agent discovers and invokes tools. The agent remains in control and calls external capabilities as needed. A2A (Agent-to-Agent) manages collaboration between two or more autonomous agents that act as peers, each with their own reasoning, planning, and ability to delegate tasks to the other.
A practical way to think about it: MCP is "agent uses a tool." A2A is "agent talks to another agent."
For external workflows (non-deterministic): if the goal is to give a single external agent a way to interact with ServiceNow, the ServiceNow MCP Server is the right choice. If the external agent needs to collaborate with a ServiceNow AI agent as a peer, exchanging plans and delegating subtasks back and forth, use an A2A Service.
For ServiceNow workflows (non-deterministic): if the third party offers an MCP Server, the ServiceNow MCP Client enables dynamic tool discovery into that system. If it offers an A2A-capable agent instead, use an A2A Service. If neither is available but the system provides a Web Service, use a standard Web Service as a tool within the AI Agent.
[D3] When to Use an Agentic Spoke as an Agent and When to Add a Tool
When the ServiceNow agent needs to interact with a third-party system deterministically via a Web Service, check the following options in order of preference:
Agentic Spoke: Now Assist for Spokes provides pre-built AI agents for third-party system integration. Currently available AI agents for Integration Hub are listed in ServiceNow docs. These are directly usable and require less maintenance, so they are preferred over a custom solution. Currently available AI agents for Integration Hub are listed in ServiceNow docs.
Tool with Subflow or Flow Action: If no Agentic Spoke exists but an Integration Hub Spoke is available or can be developed, wrap its actions in a Subflow or Flow Action and register it as a tool. This keeps the integration low-code and maintainable.
Scripted Tool with RESTMessageV2: If no Spoke exists or can be built, a scripted tool calling the third-party API directly via RESTMessageV2 offers full flexibility but requires more development and maintenance effort.
[D4] Systems Without APIs
When the third-party system provides no Web Service, no MCP Server, and no A2A-capable agent, the remaining option depends on how the system can be accessed. For Windows desktop applications, Agentic Desktop can automate interactions through the application UI. For browser-based systems, a Web Agent can automate interactions through the website. Both are goal-oriented and more resilient to UI changes than traditional scripted RPA, but slower than API-based patterns and harder to audit for compliance. These should be treated as a last resort when no programmatic interface is available.
Please note that Agentic Desktop requires a Windows environment with the ServiceNow Automation Engine agent installed. Web Agent requires browser access from a ServiceNow-controlled environment. Both require careful network and authentication configuration. Plan for these infrastructure prerequisites during solution design, not during implementation.
[E] UI-level Integrations
When the need arises to display ServiceNow data or processes within a different application's user interface, the ServiceNow platform offers several capabilities. The right choice depends on whether you are embedding web components, integrating into a mobile app, surfacing a chatbot or AI assistant, or overlaying ServiceNow content in a browser.
[E1] Web Components
The first question is whether the goal is to add ServiceNow web components to a third party portal or website.
For any webpage, Web Embeddables allow you to embed interactive ServiceNow UI elements directly into external web pages. This is useful when you want to bring specific ServiceNow functionality, such as forms, catalog items, or knowledge articles, into an existing portal without building a full integration. Web Embeddables are lightweight, configurable, and do not require the host application to implement ServiceNow APIs. They do require a custom URL on the ServiceNow instance and CORS configuration, and may need Content Security Policy (CSP) adjustments on the host website. Test cross-origin behavior early in development to avoid deployment surprises.
If the external system is Adobe Experience Manager, a set of predefined ServiceNow Components for AEM exists that surfaces ServiceNow data and processes natively within AEM-managed pages. For any other website, use Web Embeddables.
[E2] Mobile App Integration
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 app UIs.
[E3] AI Assistant and Chatbot Integration
If the goal is to surface an AI assistant or chatbot on an external website, the right capability depends on the target audience.
For customer or consumer facing scenarios, Engagement Messenger is a ready to use integration capability that can be plugged into an existing website with minimal configuration.
For employee facing scenarios, the choice depends on which employee experience product is in use. If Virtual Agent is the platform, the Portable Virtual Agent chat widget can be placed on any website. If EmployeeWorks is in use, the Embedded AI Assistant provides an integrated conversational experience within external pages.
If no chatbot is needed but the goal is to give employees quick access to Employee Center from any webpage, the Browser Extension for Employee Center overlays Employee Center directly in the browser without embedding anything into the host site.
[E4] iFrame
If none of the above capabilities apply, but you can influence the HTTP response headers on the third-party site, you can embed ServiceNow content via an iFrame. However, iFrames should only be used as a last resort. They introduce security concerns around cross-origin policies, complicate communication between embedded and host applications, and affect how users experience the content.
If none of the specific UI integration capabilities are applicable, you need to consider other integration methods.
[F] Fallback Solutions
When none of the primary integration methods (Web Services, Zero Copy, Event-Driven, AI Agents, UI-level) are applicable, the fallback branch offers alternative approaches. These methods have inherent limitations regarding reliability, scalability, and maintainability, so they should only be used when no better option is available.
Before choosing any fallback approach, first confirm with the third-party system vendor that they do not offer an API, webhook, or file export capability. Many systems that appear API-less actually have undocumented or separately licensed API options that would be far more reliable than UI automation.
[F1] Direct Database Access
If the data is stored in a database and can be retrieved or modified via SQL, two options are available depending on the use case:
For process interaction, where ServiceNow needs to query or update external database records as part of a workflow, the Flow Designer Action JDBC Step provides a low-code way to execute SQL statements from within a Flow.
For data import, where the goal is to bring external database content into ServiceNow tables, a JDBC Data Source allows scheduled or on-demand imports using standard Import Set processing with Transform Maps.
[F2] File-based Exchange
If data can be exchanged via file, the approach depends on the file type and direction of data flow.
For image or PDF files (JPEG, PNG, PDF), Document Intelligence can extract structured data from unstructured documents using AI-powered recognition.
For other file types, consider the initiating system. When ServiceNow triggers the exchange (outbound), data can either be pulled into ServiceNow from the other system using a file type data source, or pushed by ServiceNow into the other system using a MID Server and Export Set.
[F3] UI Automation
If the UI is stable and the workflow is predictable, Robotic Process Automation (RPA) Hub can automate interactions by mimicking user actions on the external system's interface.
If the UI is not stable or the workflow is not predictable, the newer AI-driven alternatives are more resilient: Agentic Desktop for Windows desktop applications or Web Agent for browser-based systems. Unlike scripted RPA, these are goal-oriented rather than click-sequence-dependent, making them better suited for interfaces that change frequently.
[F4] Email-based Exchange
If data can be exchanged via email, the direction and timing determine the right approach. When ServiceNow initiates (outbound), use Notifications for real-time delivery or Scheduled Reports for periodic data exports. When a third-party system sends data into ServiceNow (inbound), a Flow Designer Inbound Email Trigger can parse incoming emails and initiate processing.
[F5] ServiceNow AI Lens
If a user can take a screenshot or photo of the data, ServiceNow AI Lens can import it. Lens requires installing a local client and capturing the screen content, so it is best suited for occasional, low-volume data entry rather than systematic integration.
If none of the above applies, only Manual Data Transfer remains. At this point, it is worth revisiting earlier branches of the decision tree to confirm that no programmatic option was overlooked.
Acknowledgments
I want to thank the following people for providing feedback and improvement suggestions:
- Bruno De Graeve, ServiceNow
- David Skowronek, ServiceNow
- Ian Leu, ServiceNow
Changelog
Version 3.2: Australia April 2026
- Restructured and improved AI Agent integration branch
- Enhanced chapter on ServiceNow Instance Integration Options
- Expanded Middleware chapter with ESB vs API Gateway distinction and tradeoff table
- Added pull/push decision matrix
- Added Process API limitations
- Added write operations guidance
- Added more decision guidance and explanations in the whitepaper
- Added the following capabilities
- SQL API for Zero Copy Access to ServiceNow
- Web Embeddables
- Agentic Desktop
- Browser Extension for Employee Center
- ServiceNow Remote Instance Zero Copy Connector
- Scripted SOAP Web services for write access
- Embedded AI Assistant (Moveworks)
- Name changes
- ERP Canvas to Zero Copy Connector for ERP
- Service Bridge to Service Exchange
Version 3.1: Zurich September 2025
- Added a dedicated section for AI Agent Integrations with Spokes, MCP, and A2A
- Added a dedicated section for copyless integrations via Zero Copy Connector
- Added Portable Virtual Agent chat widget
- Added iFrame
- Added ServiceNow Lens
- Formatting changes and added more explanations to various decision points
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 a remark to Spoke Generator
24 Comments
