Week 20: Outbound Integrations, Import Sets & MID Server Basics

Week 19 covered request/response integrations, one record or one query at a time. This week is about the other shape integrations take: moving data in bulk, and reaching into networks the cloud instance can't touch directly on its own.

Module 20 of 25 Week 20 of 26 ~3–4 Hours Hands-on Exercise Included

By the end of this week, you'll be able to

  • Configure an Outbound REST Message record for a reusable external call
  • Explain what Import Sets and Transform Maps are for and how they relate
  • Describe what a MID Server does and why it's needed for certain integrations

1. Outbound REST Messages: Reusable, Configured Calls

Week 19's RESTMessageV2 can be built entirely in script, but for a call your team reuses often, a REST Message record (System Web Services > Outbound > REST Message) stores the endpoint, headers, and auth configuration declaratively — script then references it by name instead of rebuilding the request from scratch each time.

using a configured REST Message from script
var request = new sn_ws.RESTMessageV2('Weather API', 'get_current'); // record name, method name
request.setStringParameterNoEscape('city', 'Kolkata');

var response = request.execute();
var body = JSON.parse(response.getBody());

2. Import Sets: Getting Bulk Data In

When data needs to come in from a CSV, an external database, or another system's export — not one record via an API call, but thousands at once — an Import Set is a staging table the data lands in first, before any of it touches your real tables. This separation matters: bad or malformed rows fail in the staging table, not in incident or your own scoped app's tables directly.

3. Transform Maps: Staging Table → Real Table

A Transform Map defines how fields in the Import Set's staging table map onto fields in a target table, plus any scripted transformation logic needed along the way (formatting a date, looking up a reference field from a name instead of a sys_id). Running the transform moves — and reshapes — data from staging into its real destination table.

conceptual field mapping
Staging table field      →  Target table field
u_import_full_name       →  caller_id (looked up via a Transform Map script)
u_import_issue_summary   →  short_description
u_import_severity        →  impact  (mapped High/Med/Low → 1/2/3)

4. What a MID Server Is For

ServiceNow's cloud instance can't directly reach into a customer's private internal network — for security reasons, nothing on the internal network is exposed outward to the cloud by default. A MID Server (Management, Instrumentation and Discovery Server) is a small Java application installed inside that internal network that establishes an outbound connection to the instance, then relays commands back and forth — it's how Discovery (Week 17), certain Orchestration workflows, and some on-premises integrations reach systems the instance otherwise never could.

The direction of the connection is the whole point

A MID Server initiates the connection outward, from inside the private network to the instance — nothing has to be opened inbound on the customer's firewall. This is why it exists as a separate concept rather than the instance just calling into the internal network directly.

5. Hands-on Exercise

Hands-on

Import a batch of records via CSV

Requirements:

  1. Prepare a small CSV with columns for a fictional "asset request" (name, department, requested_item, quantity) — 5–10 rows.
  2. Create an Import Set table by loading the CSV through System Import Sets > Load Data, letting the platform auto-generate the staging table.
  3. Create a Transform Map from that staging table onto a custom table of your own (or a table you built in an earlier week's exercise), mapping at least three fields.
  4. Run the transform and confirm the target table now has one real record per CSV row, with fields populated correctly.

6. Knowledge Check

Four quick questions. Expand each to check your answer.

Q1

What advantage does a REST Message record have over building every outbound call from scratch in script?

It stores the endpoint, headers and auth configuration declaratively, once, as a reusable record — script then references it by name and method rather than rebuilding the same request configuration from scratch in every place that needs to make the call.

Q2

Why does an Import Set land bulk data in a staging table instead of writing directly to the real target table?

Separating staging from the real destination means malformed or bad rows fail in the staging table, isolated from tables like incident or a scoped app's own tables — the transform step (via a Transform Map) is a deliberate checkpoint between raw imported data and production data.

Q3

What does a Transform Map actually do?

It defines how fields in an Import Set's staging table map onto fields in a target table, including any scripted transformation logic needed along the way — like reformatting a date or looking up a reference field from a plain name instead of a sys_id — and running it moves and reshapes the data from staging into its real destination.

Q4

Why is a MID Server needed for some integrations instead of the instance just connecting directly?

ServiceNow's cloud instance can't reach into a customer's private internal network directly, for security reasons — nothing on that network is exposed outward by default. A MID Server, installed inside the private network, initiates an outbound connection to the instance instead, so nothing needs to be opened inbound on the customer's firewall.