The problem MID Server solves
ServiceNow is cloud-hosted. Your on-premises systems (internal databases, file servers, SNMP-managed network devices, internal REST APIs behind a firewall) are not reachable from the internet. MID Server sits inside your network and bridges the gap.
How MID Server works
MID Server initiates an outbound connection to ServiceNow on startup. ServiceNow sends work items (called ECC Queue messages) down that connection. MID Server executes the work (run a probe, make an API call, execute a discovery scan), then sends results back up through the same connection.
This means: no inbound firewall ports needed on your side. MID Server only makes outbound connections.
When you need a MID Server
- Discovery — scanning your network to populate the CMDB. MID Server needs line-of-sight to the devices being scanned.
- Integrations with internal APIs — calling a REST API that lives behind your corporate firewall
- JDBC integrations — connecting to on-premises databases (SQL Server, Oracle, etc.)
- Orchestration against internal systems — running scripts or PowerShell against internal servers
- SNMP polling — monitoring network devices via SNMP
When you do NOT need a MID Server
- Calling public REST APIs accessible from the internet
- ServiceNow-to-ServiceNow integrations (same platform)
- Webhook receivers (inbound to ServiceNow)
- Any system accessible directly from ServiceNow's cloud IP ranges
MID Server capacity planning
One MID Server can typically handle moderate Discovery and integration load. For large enterprises: use MID Server clusters (multiple MID Servers in a pool) for redundancy and load distribution. Configure affinity so specific integrations always use specific MID Servers.
MID Server in Flow Designer
When adding a REST step in Flow Designer, you can specify which MID Server to route through. This is how you call internal APIs from a Flow without writing custom scripting.