Time to continue the Remote Table journey! In Part 1, we established that a Remote Table acts as a sophisticated virtual bridge; a window into data residing outside our instance. We discussed why this is powerful: achieving real-time fidelity without the baggage of data duplication. But concepts, no matter how elegant they may be, only become truly impactful when you see them in action!
For this deep dive, I built a Proof of Concept in my Personal Developer Instance to demonstrate exactly how we make ServiceNow talk to an external system. We are going to pull live data from a vendor ticketing system directly into our native Incident form, turning that abstract connection into a concrete, operational feature for our internal support teams.
The Scenario
Let’s imagine we use an external vendor management portal (let's call it VendorX) to manage critical maintenance or specialised hardware tickets. These are Vendor Tickets. Service Desk Agents need visibility into the status of these corresponding Vendor Tickets without having to constantly log into the VendorX portal, manually cross-reference IDs, and then copy/paste the latest updates.
The Goal
When an internal user views a ServiceNow Incident record, they should see the latest State, Work Notes, Last Updated timestamp, and Resolution details directly from the external VendorX system, all surfaced neatly on our form.
This is where Remote Tables shine. We are not importing all of VendorX’s data; we are creating a highly specific, contextualised view for a single ServiceNow record based on a shared identifier.
The Mechanism: Correlation and Connectivity
The key to this entire process lies in establishing the connection protocol and defining a reliable lookup mechanism. In our POC, we used two crucial elements:
- The Remote Table Schema: Here we define a table structure within ServiceNow that mirrors the critical fields from VendorX (e.g., vendor_ticket_id, state, last_updated, work_notes, etc.). This definition is the blueprint for our virtual window.
- The API Gateway: The actual data retrieval relies on robust connectivity—in this case, a REST API call to VendorX’s endpoint. Here we configure the Remote Table definition using a simple script using the RESTMessageV2 capability or a REST Step via Flow/Subflow to return and then parse the data.
But how does ServiceNow know which vendor ticket to pull when an internal user opens Incident INC0010009? This is where we introduce a critical architectural pattern known as contextual linking, managed through our shared identifier: the Correlation ID.
In our POC, when the initial Vendor Ticket was logged into the local Incident form, the support agent captured the external vendor’s unique identifier (e.g., VTS-71239) and stored it in a designated field on the ServiceNow Incident record (we used the standard Correlation ID field for this purpose). This ID becomes the handshake between our two systems.
The Remote Table configuration is then designed not to pull all records from VendorX, but specifically to query based on input parameters (e.g., <vendor endpoint>/api/external/tickets?query=VTS-71239). When we build the related list on the local Incident form, we are essentially telling ServiceNow: "For this specific Incident record, look at its Correlation ID value, and use that value as the primary filter when querying the Remote Table."
Architectural Takeaways for Architects
What does this demonstrate architecturally? It proves that Remote Tables are not just useful for simple lookups; they enable contextual enrichment. We have successfully attached a dynamic, external data feed to a native record without ever having to write complex, scheduled ETL jobs or store potentially stale data locally.
This capability is transformative for user experience and data governance. Our team gets the operational insight it needs (knowing if VendorX has marked VTS-71239 as "Resolved") without incurring the maintenance overhead of synchronising two independent systems.
In Part 2, we've explored the most common Remote Table use case - retrieving data from remote systems. In Part 3, we'll think outside the box and work with data from within ServiceNow!
What are your thoughts? Have you experimented with REST API integration for external visibility before? Let me know in the comments below!
