This guide summarizes recommended integration options for connecting ServiceNow with third‑party systems and when to choose each approach.
A. Web Service Integrations
Web services are the preferred approach due to broad industry adoption and interoperability. They offer flexibility to connect disparate platforms and adapt as business needs evolve.
A1. Usage of an ESB or Integration Middleware
An Enterprise Service Bus (ESB) or middleware can connect diverse apps and centralize message handling. Consider:
- Most ServiceNow plugins, Store apps, and IntegrationHub spokes assume the native third‑party API. If the middleware does not mirror that API, heavy customization increases cost and complexity.
- Middleware introduces extra points of failure for stability and security.
- Some ITOM solutions (Discovery, Service Mapping, Orchestration) require a MID Server regardless.
A2. ServiceNow Instance Integration Options
For instance‑to‑instance integration, consider the following:
Service Bridge
Designed for Telco/Tech/MSP provider‑consumer scenarios (provider vs customer instances). Limited flexibility for general data sync and requires agreement on integration approach.
Instance Data Replication (IDR)
Replicates updates one‑to‑many or bidirectionally for near real‑time sync of large data sets. Can only sync reference fields if the referenced table is also synchronized; replication sets are limited in size. Review product limits before choosing.
Remote Process Sync (RPS)
Synchronizes processes with flows designed on both instances; supports ordered message execution even with connectivity issues. Good for task/process replication; may be heavy for simple use cases.
Remote Instance Spoke
OOTB actions for ad hoc instance‑to‑instance calls. Simple to start, but not ideal for heavy usage—flow logic, security, and error handling are your responsibility.
If none of these fit, evaluate other data transfer options (e.g., IntegrationHub Import) using your internal decision tree.
A3. Using an Out‑of‑the‑Box (OOTB) Solution
Native Integration (Plugin or Store App)
Ready‑made connectors (e.g., HR with SuccessFactors) minimize build effort—prefer them when available.
IntegrationHub Spokes
Low‑code actions to call third‑party APIs from flows. Faster than custom builds; more effort than fully packaged native integrations.
Extending a Spoke with Spoke Generator
Import an OpenAPI spec or use Now Assist with API docs to extend an existing spoke—typically better than a bespoke build.
Technology Partner Store Apps
Check the ServiceNow Store for partner‑provided integration apps that already solve your use case.
A4 & A5. Initiating System and Pull vs Push
Initiating System
The system that starts the integration (ServiceNow or the third‑party). Example: ServiceNow initiates when it fetches external foundation data; a third‑party initiates when it creates a ticket in ServiceNow.
Pull vs Push
- Pull: ServiceNow retrieves data from another system (e.g., fetch via REST and store in a table).
- Push: ServiceNow sends data out (e.g., replicate tickets to a data warehouse).
Choose based on frequency, volume, complexity, security/performance, and third‑party capabilities. Establish platform‑wide guidelines to stay consistent.
A6. Process (REST) APIs
Process‑specific APIs (e.g., Catalog, Change) expect strict payload formats and may bypass certain validations you could implement elsewhere (Transform Maps, RTE). Validate suitability case‑by‑case.
A7. Choice of Web Service Protocol
- REST: Recommended—widely adopted, easy to debug, JSON payloads.
- GraphQL: Precise data selection; requires custom schema and more engineering effort.
- SOAP: XML‑based and verbose; avoid unless required by legacy systems.
- ODBC: Direct DB access; consider only as last resort.
A8. Table API vs Scripted REST API
- Table API: Predefined, no setup—works for most tables.
- Scripted REST/SOAP API: Flexible and customizable—more effort to build and maintain.
Prefer exposing ServiceNow’s native structures and let external systems transform. If transformation is required in ServiceNow, a Scripted REST API that invokes a Subflow (low‑code) is a maintainable approach.
D. AI Agents
On the Now Platform, AI agents enhance automation and cross‑platform execution. Because they are non‑deterministic, integrations should be flexible and adaptive.
- REST/Web services (often via IntegrationHub spokes)
- MCP (Model Context Protocol) — agent‑to‑tool
- A2A (Agent‑to‑Agent) — cross‑platform agent interoperability
- Agentic Spokes and per‑agent tools within AI Agent Studio
D1. A Deterministic Web Service might be the Better Choice
REST APIs provide clear contracts and predictable schemas—ideal for stable, auditable, compliant integrations. MCP enables dynamic tool discovery but introduces variability in tool availability and response formats. For regulated workflows, prefer REST.
D2. MCP vs A2A
MCP: Standardizes tool discovery/invocation; best when flexibility and rapid capability extension matter.
A2A: Manages inter‑agent coordination across platforms; best for multi‑agent plans and result exchange. Use MCP to extend one agent; use A2A when multiple agents must collaborate. They can be layered together.
D3. When to Use an Agentic Spoke as an Agent vs Add a Tool
Prefer an Agentic Spoke (Now Assist for Spokes) when available—ready to use and lower maintenance. If unavailable, equip a custom agent with a Tool (ideally a Flow Action encapsulating web‑service logic) rather than bespoke scripting.