I can't believe it's been over 5 years since Jai Rangam and I recorded the CreatorCon lab, Working with Remote Tables for Knowledge 20. I’m thrilled to dive back into this deep technical topic that always fascinates me: how do we make ServiceNow talk seamlessly to the rest of the digital ecosystem? We all know how powerful our instance is; it’s the central nervous system for many organisations. But what happens when the critical data you need lives outside of ServiceNow, perhaps buried deep in Workday or sitting pristine on an AWS database? That's where Remote Tables step onto the stage!
To put it plainly, a Remote Table isn't just another table; it’s a virtual bridge. Think of it like installing a sophisticated window directly into another system’s data repository. You aren't actually copying or storing that external data locally within your ServiceNow instance; that's the key. Instead, you are giving ServiceNow the power to look through that window and see live, up-to-the-minute information from those external systems as if it were one of our own native records. Pretty cool, right?
Why should any architect or developer care about this magic trick? It boils down to two massive wins: data integrity and system efficiency. By embracing Remote Tables, we immediately sidestep the nightmare of constant, costly data duplication. We don't need to build complex ETL processes just to keep a static copy updated; we get real-time fidelity. Plus, let’s talk about "table bloat". That slow, insidious growth of unnecessary local records. Remote Tables help us fight it by keeping our internal database lean and mean. This means you can leverage external insights directly within your forms, reports, or portals, all while maintaining the smooth, native ServiceNow user experience.
So, how does this virtual connection actually work under the hood? Well, when we set up a Remote Table, we are essentially defining the protocol for communication. We’re telling ServiceNow how to talk to the other system, and that usually means leaning heavily on robust connectivity methods like REST or SOAP APIs. The setup involves getting a little technical: (1) configuring the table definition so it's visible throughout the platform, and (2) configuring the connection so data can be retrieved from the source.
While the ability for perpetual data freshness is fantastic (making them perfect for read-only scenarios where latency tolerance is low), we can’t ignore the constraints. Because the source of truth resides externally, network latency or slowness in that external system will eventually impact your performance within ServiceNow. Furthermore, while we can certainly reference complex fields from these remote sources, if you start trying to perform heavy local manipulations on that live data, you'll need some careful scripting choreography to manage how that external state interacts with your internal business logic. Some key points to note are:
- By default, Remote Tables are limited to 1000 rows (although this can be extended by enabling the Enhanced Capacity option).
- Remote Tables are Read-Only by default, but can be configured as Editable. A different script is used for each operation (e.g., Query, Insert, Update, Delete). Note that if configured this way, the Enhanced Capacity option cannot be used.
- Caching of results is possible and can be configured with a TTL value per Remote Table definition. This can significantly reduce the number of external integration transactions. Caching can apply to either a user session or all users. The maximum is 60 minutes.
- You can use a Flow rather than a Script to populate your Remote Table data.
Pro Tip:
Filter Conditions added to the List View are not automatically passed to the integration query. This means that your integration may retrieve much more data than is needed. To improve performance, use the available functions to pass the Filter Conditions from the List View to the integration query. For example, if the Filter Conditions are "Active is true AND Category is Hardware", pass these details to the integration query so that only the records matching these conditions are returned and added to the Remote Table. As shown below, the default code snippet (shown below) shows some of the functions that make this possible. Note there is a function called isGet() which can tell your script whether the query is from the List View (false) or the Form View (true).
Well, that's it for Part 1. Stick around for Part 2 as this journey into data integration is just getting started!
