ServiceNow for FDEs: Integration Hub, Scripted REST and MID Server at large enterprise clients

On your third day at the client, you discover that the asset database your agent needs to read sits on the internal network, while the ServiceNow instance runs in the cloud. The demo that ran nicely on your laptop is no help now. The question is how to get the two talking, in a way the bank’s security team will accept.

ServiceNow says 85% of the Fortune 500 are its customers. If you work as an FDE for large enterprises, there is a good chance you will meet a ServiceNow instance somewhere along the data’s path.

Three tools decide whether that integration makes it to production: two handle the direction of the data, and the third handles where the target system lives.

Ask first: which way does the data flow, and where does it live?

The simplest division of labour is this. When your system needs to call into ServiceNow, you write a Scripted REST API. When ServiceNow needs to call out, you use an Integration Hub spoke.

Client need	Tool	What to remember
An external system calls into ServiceNow	Scripted REST API	Version in the URI; for major changes, create a new version first
ServiceNow calls out to another system	Integration Hub spoke	Record steps run on the instance, steps that reach the client network run on the MID
The target system sits inside the client’s network	MID Server	JDBC, LDAP and export set sources use a dedicated MID

MID Server: the gatekeeper inside the client’s network

ServiceNow’s official documentation describes the MID Server as the intermediary between the client’s network and the instance. When you sit down with the client’s security team, use that description as the starting point for drawing where the data flows, then confirm with them exactly which connections need to be allowed.

In production, a single MID Server is a single point of failure: if it dies, the whole flow stops. A failover cluster solves this with a preconfigured order that determines which MID Server takes over next when something goes wrong.

The price of a cluster is the risk of duplicate data. After failover, tasks in the ECC queue restart from the beginning, so a half-finished JDBC read can be written twice. Clusters also do not support the ECC queue topics Command and SystemCommand.

Integration Hub: when do you need a spoke?

Integration Hub is a low-code tool on the Now Platform that extends Flow Designer to integrate with third-party APIs. On cost, Perspectium says pricing is based on transaction volume and the number of spokes, and the free Starter tier is capped at 1,000,000 transactions a year. Check that figure against the client’s actual licence before you make promises about volume.

Most of the time, you will be working with spokes. Each spoke bundles related actions, subflows and supporting files in one place to connect to a specific system. Imagine the client needs ServiceNow to look up and update an internal asset inventory.

Rather than scattering individual REST steps across many flows, you bundle “look up asset by ID” and “update status” into an “Asset inventory” spoke that every flow can share.

Because the asset inventory sits inside the client’s network, the step that calls it runs on the MID Server, while the step that writes the result to the record runs on the instance. ServiceNow advises against switching the execution environment back and forth many times. In this example, let the MID Server finish all its work with the asset inventory, then return the result in one go.

Scripted REST: the door for your agent

In the other direction, when your agent or service needs to create or read records, a Scripted REST API lets you build the web service you want. Its most valuable feature is that the version number sits in the URI, so you can test and release changes without touching integrations that are already running.

ServiceNow’s rule is clear: when there is a major functional change, create a new version first. At a large enterprise, an endpoint may be called by many teams, and you often do not know who all of them are.

Four mistakes that break integrations in production

The first: putting the MID Server that reads JDBC into a cluster “to be safe”. ServiceNow recommends a dedicated, unclustered MID Server for LDAP, export set and JDBC sources, precisely because of the risk of duplicate data after failover.

The second: releasing an endpoint without a version, then changing the behaviour of the live version directly. Another team’s client breaks and you never find out.

The third: a flow that jumps between the instance and the MID Server many times, which ServiceNow advises against. The fourth: pushing large volumes of data through Integration Hub. Perspectium warns this can noticeably slow the ServiceNow platform, and the people who pay for it are every other user on the client’s instance.

Putting it together in a concrete case

Picture the full flow. The agent calls the v1 endpoint to open an incident, then a flow calls a spoke action that looks up the asset in the internal database. That action runs on a dedicated MID Server reserved for JDBC, finishes its work inside the client’s network, and only then returns the result to the instance.

If you want to learn this, start with Scripted REST on a personal instance, since it is closest to the backend skills you already have. Then move on to spokes, and finally to the MID Server.

On your CV, do not just write “worked with ServiceNow”.

Write a specific line, for example: “Built a versioned Scripted REST API (v1, v2) for an agent that creates incidents; queried an internal asset database over JDBC on a dedicated, unclustered MID Server.” When you read FDE job postings for enterprise clients, look for mentions of ServiceNow or internal systems, and put that exact line at the top.

The people who assess you at a large client rarely ask how clever the agent is. They ask whether it can get through the firewall without duplicating a single row of data.