6/10/25 - This post has been updated to include a YouTube video walking through theses steps and showing a demo of it in action. The Remote Table column names have been updated to match the video walkthrough. This demo was created on Zurich instances using the Service Bridge for Providers/Consumers version 2.1.20 plugin.
Overview
In Service Bridge’s Remote Catalog, Remote Choice allows for real-time, dynamic choice population by pulling the data from provider instance in real time. This ensures accurate and complete data, and removes the effort, complexity and scalability challenges of configuring replication of data to multiple customers.
You may have external data sources that you want to make available as choices with Remote Choice. This is where Remote Tables, a ServiceNow platform capability, can work well with Remote Choice. With Remote Tables you can create a ‘virtual table’ that will dynamically populate data from an external data source, whenever it is queried.
This post has an accompanying YouTube video walking through the steps and seeing it in action - YouTube: Service Bridge - Remote Tables with Remote Choice
Remote Tables Overview
You create remote tables to describe the schema for the data that you want to retrieve from an external source.
The table definition is in the Now Platform, but its rows, or external records, live in memory. You create a remote table the same way that you would create a standard internal table. You define columns and controls and designate application access for it just like you would do for an internal table. Unlike an internal table, a remote table doesn’t get its records from the Now Platform database. It gets its records from running an associated query script against an external data source.
https://www.servicenow.com/docs/csh?topicname=remote-tables.html&version=latest
Remote Choice Overview
Remote choice fields provide your consumers direct access to your (provider) data in real time while they submit a remote catalog item from their instance.
Remote choice fields enable consumers to view the choice list for a catalog reference field directly from the provider's instance. They provide the following advantages:
- Removes the need to replicate foundation data.
- Reduces the cost and maintenance of integrations.
Walkthrough
Lets go through an example showing this in action
- Create a Remote Table:
- On the Provider instance navigate to System Definitions>Remote Tables>Tables.
- Click on the New button and on the new record give your table a label and name. For our purposes we done need to create modules, so those options can be unchecked, and then save the record.
- Add two string fields which will be the fields displayed to the consumer in the choice list as the display field and additional info field. In my example I named them “Temperature” and “Time”.
2. Create the Remote Table Definition:
- Next we'll create a remote table definition. Navigate to System Definitions>Remote Tables>Definitions and click on the new button.
- In the new record enter a name and then select the table name of the Remote Table that you just created in the previous step.
- Lastly we need to create the script that will call to the external data source to get the data to create the records to be returned.
- For the example here, I will use a public weather API that you can use to test yourself. This example will set the time returned as the time field and the temperature as the temperature field.
- Note: It is critical that you return a sys_id that will be unique to the records returned. If the sys_id is populated the record will not be displayed on the consumer side once selected. The sys_id returned should also be unique to the record returned. Records are cached on the consumer side to display values on the form after submitted, so if the sys_id fields are not unique, you will see wrong display values.
(function executeQuery(v_table, v_query) {
try {
var restMessage = new sn_ws.RESTMessageV2();
restMessage.setEndpoint('https://api.open-meteo.com/v1/forecast?latitude=40.71&longitude=-74.01&hourly=temperature_2m');
restMessage.setHttpMethod('GET');
var response = restMessage.execute();
var responseBody = response.getBody();
var httpStatus = response.getStatusCode();
if (httpStatus === 200) {
var data = JSON.parse(responseBody);
var times = data.hourly.time;
var temperatures = data.hourly.temperature_2m;
gs.print('Hourly Temperature Forecast:');
for (var i = 0; i < Math.min(times.length, 5); i++) {
var row = {};
row["u_time"] = times[i].toString();
row["u_temperature"] = (temperatures[i].toString() + ' °C');
row["sys_id"] = ('1234567890123456789012345678902' + i.toString());
v_table.addRow(row);
}
} else {
gs.error('HTTP error: ' + httpStatus);
}
} catch (ex) {
gs.error('Error: ' + ex.message);
}
})(v_table, v_query);3. Configure Remote Choice:
- Navigate to Service Bridge> Administration>Remote Choice Definitions. Note: You will need to elevate your role to security_admin to create or edit a Remote Choice Definition.
- Click on the New button to create a new definition. Select the Remote Table that you created and enter a name. We will not create a filter for this example. Once completed publish the Remote Choice Definition.
4. Configure the Variable in the Remote Catalog Item
- Out last step will be to configure a variable on the Remote Catalog Item to use the Remote Choice. On the Remote Catalog Item you would like to test this on, create a new variable.
- Set the variable as a Reference type and select the “Remote Choice Enabled” option. Enter the question and then go to the type specification tab.
- Select the Remote Choice Definition you just created and set your display field (optionally additional info).
- Once completed you can publish the Remote Catalog Item
5. Test it
- On the consumer instance, they only need to approve the Remote Catalog Item if not set to auto-approve.
- When the consumer clicks on the drop down list, the choices will be populated from external data source through the Provider instance.
