ServiceNow MID Server Integration Patterns

Inbound Versus Outbound Integration Patterns

MID Server integration patterns fall into two categories: inbound (data flows from external systems into ServiceNow) and outbound (data flows from ServiceNow to external systems). Inbound patterns are often triggered by an external system sending data via API or files; ServiceNow receives it and processes it. Outbound patterns are triggered by action in ServiceNow (a record is created or updated), and ServiceNow sends data to external systems via API or files.

Hybrid patterns involve both: a request arrives in ServiceNow, an orchestration or integration sends it to an external system, waits for a response, and updates the ServiceNow record with the result. All three patterns can be implemented with MID Server, but understanding which is appropriate for your use case simplifies design.

Inbound Patterns: Push and Pull

Inbound push patterns: the external system sends data to ServiceNow via an MID Server. For example, a monitoring system sends events to an event ingestion endpoint on a MID Server, the server processes and transforms them, and pushes them into ServiceNow. This pattern works well when the external system is the driver: it knows when to send data and pushes on its own schedule.

Inbound pull patterns: ServiceNow polls an external system via an MID Server. For example, ServiceNow Discovery probes remote systems via an MID Server and pulls their configuration. Or a scheduled job in ServiceNow calls an external API via the MID Server to fetch updated data. Pull patterns work well for periodic synchronization or when the external system does not support outbound push.

Push is often more efficient for real-time data; pull is simpler to implement and manage because ServiceNow controls the schedule and can easily retry. Choose based on your data freshness requirements and the capabilities of the external system.

Outbound Patterns: Fire and Forget, Wait for Response, and Callback

Fire-and-forget patterns: ServiceNow sends data to an external system and does not wait for acknowledgment. This works for notifications or events where ServiceNow does not care about the result. The risk is that the external system might not receive the data, and ServiceNow will not know. Use fire-and-forget only for non-critical notifications.

Wait-for-response patterns: ServiceNow sends data to an external system and waits for a response before continuing. This works for orchestrations that need immediate feedback: provision a resource, wait for confirmation, then continue. The risk is that if the external system is slow, the integration becomes slow. Also, long-running outbound waits consume resources.

Callback patterns: ServiceNow sends data to an external system asynchronously. The external system processes the request and later calls back to a ServiceNow endpoint with the result. This pattern is efficient for long-running operations: provision a resource (takes time), request completes, external system later calls back to say provisioning is done. ServiceNow continues and processes the callback without waiting.

Choosing Between Integration Approaches

Multiple integration approaches exist in ServiceNow: REST APIs, SOAP integrations, MID Server, Integration Hub, and custom scripts. When should you use MID Server?

Use MID Server when: the external system is on-premises or not internet-reachable (MID Server bypasses firewall constraints), you need to transform or enrich data during integration (MID Server can run scripts), you need to integrate with systems that do not have APIs (MID Server can read files or databases directly), or you need additional control and logging during integration.

Use direct REST or SOAP when: the external system is internet-accessible and has a well-documented API, you do not need significant data transformation, and simplicity is important. Direct APIs are simpler to configure and monitor.

Use Integration Hub when: you are building complex multi-step workflows that coordinate across systems. Integration Hub is purpose-built for this.

Error Handling and Retry Strategy

MID Server integrations will fail: network timeouts, API errors, authentication issues. Design error handling explicitly: should failures retry automatically, how many times, with what backoff? Should failures escalate to a support team, or are they expected and handled gracefully?

Implement retry logic: exponential backoff (first retry after 1 second, second after 2 seconds, third after 4 seconds) prevents overwhelming an overloaded system. Limit retries so failed integrations do not hang indefinitely. Log each retry so you have visibility into failures.

For critical integrations, implement dead-letter queues: if an integration fails after all retries, put the message in a queue for manual review rather than silently dropping it. This ensures critical data is not lost and humans can investigate why integration failed.

Monitoring and Ownership of MID Server Integrations

MID Server integrations require ongoing monitoring: are they running successfully, what is the latency, are there error spikes? Set up dashboards showing integration health and alert when failures exceed a threshold.

Also establish ownership: who is responsible for the integration, monitoring it, updating it when external systems change? Without clear ownership, integrations accumulate and maintenance becomes reactive—integrations break, teams scramble to fix them.

Document integrations: what does it do, what systems does it connect, how is it monitored, who owns it, and when was it last reviewed? Documentation makes it easier for new team members to understand and maintain integrations, and makes it easier to decide which integrations to retire if they are no longer needed.

Designing MID-backed integrations around the ways they fail

An integration that runs through a MID Server is only as dependable as its response to the moment something goes wrong. The happy path is rarely where the design effort pays off. The harder cases are a target system that accepts a request and then times out before replying, a server that restarts with a backlog of work already in progress, and a retry that sends the same record twice because nobody agreed what a duplicate means. Designing for those cases first tends to produce simpler integrations than designing for the normal flow and patching the failures afterwards.

The question for the integration designer is not only which pattern to use but what the business will accept if the message is delayed, duplicated or lost. The answers differ by use. A status read can be repeated safely. A record creation may not be.

Matching each failure to a design response

The table pairs the failures most often seen in MID-backed work with the design responses that handle them. Read each row as a question to answer for the specific integration, not as a rule to copy across the estate.

A checklist for signing off an integration design

Before an integration runs unattended, the design should be able to answer the following in order. Each answer should be written into the integration’s record so the operations team can use it at three in the morning.

1. What does a duplicate request do to the target system, and how is it detected?
2. How old can a queued request become before it stops being worth sending?
3. Which failures page a person, and which are only recorded for review?
4. What is the manual procedure for reprocessing the work after an outage, and who is allowed to run it?
5. How will the team know the integration has silently stopped, rather than failing loudly?

The last question is one that teams often leave unanswered. An integration that fails loudly is easy to notice. One that simply stops sending, while the monitoring keeps reporting a healthy server, can run for a long time before anyone checks the data it was meant to deliver.

Keeping the integration observable after it goes live

Observation is a design feature, not a reporting afterthought. Track the age of the oldest unprocessed request, the proportion of requests that needed a retry, and the number of duplicates detected, rather than only counting successes. A rise in any of those is an early warning that the design is no longer matching the traffic. The metrics that support this kind of tracking are set out in the MID Server KPI guide. For orchestration that calls MID-backed steps, the orchestration integration patterns guide covers the orchestration of multi-step processes around those calls.

When an integration keeps producing duplicates or stalls at the same point, the cause is often in the design rather than in the server.

Related guides: Troubleshooting ServiceNow MID Server: A Practical Guide.