ServiceNow REST and SOAP Integrations Integration Patterns

The choice between a synchronous request-reply call, a publish-subscribe queue, a batch synchronisation or a webhook decides whether an integration with ServiceNow stays fast and recoverable or becomes the slowest step in a workflow. This page sets out each pattern with its trade-offs and the ServiceNow mechanism it maps to, how to keep synchronous calls out of the path of bulk work, an ordered check for choosing a pattern, and the things that look like integrations but are not.

Pattern 1: Request-Reply (Synchronous)

A ServiceNow workflow creates an incident and immediately needs the customer’s latest contact information from the CRM system. A REST request is sent to the CRM: “Get customer record for ID X.” The CRM responds with the record. The workflow uses that data to populate incident fields and continues. The entire interaction completes in seconds.

Pros: simple to understand and debug, data is current (no staleness), errors are immediate and can be handled in the workflow.

Cons: slow if the remote system is slow (the workflow waits for a response), creates tight coupling (if the CRM is down, the workflow stalls), and can create scaling issues (if many workflows make simultaneous requests, the CRM gets hammered).

Use when: data must be current, latency is acceptable for the use case, and request volume is moderate.

Pattern 2: Publish-Subscribe (Asynchronous)

A ServiceNow incident is created. Rather than synchronously asking the CRM for data, ServiceNow publishes a message: “Incident created, ID X, customer ID Y.” A message queue holds the message. The CRM system consumes the message at its own pace, enriches it with customer data, and publishes a response: “Customer enriched, incident ID X, contact updated.” ServiceNow consumes the response and updates the incident. The whole interaction takes seconds to minutes, not blocking the initial incident creation.

Pros: decouples systems (CRM can be slow or temporarily unavailable), scales well (queue absorbs traffic spikes), allows for parallel processing (multiple CRM workers process requests simultaneously).

Cons: more complex to implement (requires a message broker), data has a slight delay (seconds to minutes), and debugging is harder (you must inspect message queues to diagnose problems).

Use when: latency tolerance is higher (data can be current within minutes, not seconds), volume is high, or systems are unstable and you need buffering.

Pattern 3: Batch Synchronization

Every night at midnight, ServiceNow exports all incident records changed in the last 24 hours to a CSV file and uploads it to an SFTP server. The finance system downloads the CSV, processes it, and updates cost tracking. A second batch pulls GL (general ledger) account codes from the finance system into ServiceNow’s cost allocation table.

Pros: simple to implement (files and scheduled jobs are straightforward), systems don’t need to be compatible (files are universal), and batch windows are predictable (scheduled at off-peak hours).

Cons: data has staleness (batch runs daily, so data is up to 24 hours old), implementation is manual (someone must verify the batch ran, check for errors, and handle failures), and debugging is tedious (examining large files manually).

Use when: data can be stale (daily updates are sufficient), volume is large (thousands of records), or systems cannot support real-time APIs.

Pattern 4: Real-Time APIs with Webhooks

An HR system changes an employee’s department. Rather than ServiceNow polling every hour to check for changes, the HR system immediately calls a ServiceNow webhook (a URL you expose that the HR system can call). The webhook updates the employee record in ServiceNow instantly. Similarly, when an incident is closed in ServiceNow, a webhook notifies the CRM to close the associated case.

Pros: data is immediately current, no polling overhead (the remote system pushes changes), responsive user experience (users see updates immediately).

Cons: requires the remote system to support webhooks (not all do), you must expose a public endpoint (security consideration), and the remote system must be able to reach your ServiceNow instance (firewall issues are common).

Use when: data must be current, both systems support webhooks, and you can safely expose an endpoint.

Pattern 5: Inbound vs. Outbound vs. Bidirectional

Inbound: data flows into ServiceNow from external systems. Example: employee records sync from HR to ServiceNow. Direction is one-way; ServiceNow is passive (receiving).

Outbound: data flows from ServiceNow to external systems. Example: when an incident is resolved, ServiceNow notifies the CRM. Direction is one-way; ServiceNow is active (sending).

Bidirectional: data flows both ways. Example: incidents sync from ServiceNow to Salesforce (outbound), and Salesforce case updates sync back to ServiceNow (inbound). Bidirectional is most complex because you must handle conflicts (what if both systems change the same record simultaneously?) and avoid infinite loops (update A triggers update B which triggers update A again).

For bidirectional integrations, establish clear ownership: which system is the “source of truth” for each field. Incident status is owned by ServiceNow (changes there propagate outbound); customer data is owned by Salesforce (changes there propagate inbound). Never allow both systems to own the same field or conflicts become unresolvable.

Choosing Between Integration Approaches

Request-reply is best for occasional lookups that must be current. Publish-subscribe is best for high-volume, asynchronous interactions. Batch is best for large data transfers with acceptable staleness. Webhooks are best when both systems support them and current data is critical.

Consider: what is the data latency tolerance (must be current or can be minutes old), how often does data change (constantly or daily), what is the volume (tens of records or thousands), and do both systems support the approach?

Error Handling and Ownership

In request-reply, the calling system (ServiceNow workflow) handles errors: if the CRM returns an error, the workflow decides to retry, queue for manual review, or fail visibly. The workflow owner is responsible for handling these cases.

In publish-subscribe, a failed message stays in the queue. A separate process must handle errors: retry the message, move it to a dead-letter queue (for manual investigation), or alert the on-call team. The integration owner must monitor the message queue and respond to failures.

In batch, if a file upload fails, the batch job fails. A scheduled job failure must be investigated and resolved manually. Have monitoring and alerting in place so batch failures don’t go unnoticed overnight.

Define ownership: which team owns the integration, what SLA is acceptable for detecting and fixing integration failures, and who is on call for integration issues.

Match each pattern to a ServiceNow mechanism

Choosing a pattern is only half the decision. The other half is which ServiceNow mechanism will carry it, because each mechanism has its own execution context, its own failure behavior and its own limits on how much work it does in one go. A pattern that looks right on a whiteboard can fail when it is built on the wrong mechanism, for example a bulk transfer forced through a form-level script. The table below pairs the common patterns with the mechanisms teams usually reach for and the risk each one carries.

Keep synchronous calls out of the path of bulk work

A frequent design error is to choose a request-and-reply pattern for a process that actually moves thousands of records. Each record then triggers its own wait on the remote side, and the process runs slowly and fragile at the same time. When the volume is large, stage the inbound data first and transform it in a separate step, so a failure in one row can be isolated and retried without repeating the whole load. The same logic applies to outbound work: group changes into batches rather than sending one message for each edit.

An ordered check for choosing a pattern

1. Write down the latest acceptable time for the data to be current, in plain words.
2. Estimate how many records change in a typical period and in the busiest one.
3. Decide which side owns each field, so that no pattern lets both systems write the same value.
4. Pick the mechanism that matches the pattern and confirm it has a place to record failed items.
5. Name the person who receives the alert when the pattern stops working.

Patterns that look like integrations but are not

Some requests describe a single integration but are really a reporting need, or a data migration, or a user interface change. A dashboard that shows another system’s figures is usually better served by a scheduled extract than by a live call from every page view. A one-off migration should be run as a migration, with its own reconciliation, not kept alive as a permanent pattern. Naming the real need first often removes the integration entirely.

Questions about choosing integration patterns

Can a business rule use a synchronous call for a small lookup?

It can, if the call is short, the remote service is reliable, and the process has a defined fallback. Without a fallback, every remote problem becomes a problem for the people saving records.

Which pattern suits a remote system with no webhook support?

A scheduled pull with a stored watermark is usually the most dependable choice. It works with almost any remote system, and the watermark makes the run restartable.

Should inbound and outbound flows use the same mechanism?

Not necessarily. Inbound data often suits a staged load or a scripted resource, while outbound notifications suit an event or flow. Matching the mechanism to the direction keeps each one easier to monitor.

Bring the pattern shortlist to a specialist

A pattern choice is cheap to change on paper and expensive to change in production. Read the REST and SOAP integrations hub alongside this guidance, and the IntegrationHub flow design note covers orchestration. The explainer on import sets describes the staging step for bulk loads, and the integration pattern explainer sets out the building blocks.