ServiceNow Integration Hub Integration Patterns
This guide helps teams choose how an Integration Hub integration should run. Pre-built spoke connectors handle authentication and common operations for systems such as Salesforce, SAP and Workday. Where no spoke exists, custom REST or SOAP integration is needed. Request-response suits operations that finish quickly, while webhooks suit event-driven updates from external systems.
Spoke Connectors and Pre-built Integrations
Integration Hub provides pre-built spoke connectors for common business systems: Salesforce, SAP, Oracle, Workday, ServiceNow-to-ServiceNow, and many others. Spokes encapsulate authentication, API knowledge, and common operations, reducing custom integration work. A Salesforce spoke handles OAuth authentication, provides methods for CRUD operations on Salesforce records, and handles pagination and error cases—work that custom REST integration would require. Spoke selection is straightforward: if a spoke exists for your system, use it. If no spoke exists, custom REST or SOAP integration is necessary. Hub-based spoke architecture means new spokes are added regularly, expanding integration capabilities.
Spoke configuration includes credential management: OAuth tokens, API keys, basic authentication credentials are stored securely in ServiceNow credential storage, not in flow code. Spoking systems also include operational defaults (timeouts, retry counts, batch sizes) that work for most use cases but can be adjusted for specific integrations. Spokes often provide test connectivity options: verify credentials are correct and the external system is reachable before declaring the integration ready.
Event-Driven and Real-Time Integrations
Integration Hub supports both request-response and event-driven patterns. Request-response (call an API, wait for response) is synchronous and works for operations that complete quickly. Event-driven (something changes in an external system, it notifies ServiceNow immediately) is asynchronous and works for decoupled systems. Webhook integration allows external systems to post updates to ServiceNow without ServiceNow polling. When a customer status changes in your CRM, a webhook notification posts to ServiceNow immediately. When a deployment completes in your DevOps tool, webhook notification triggers follow-up actions in ServiceNow.
Real-time integrations require resilient error handling: external systems may be temporarily unavailable or send malformed data. Webhook handlers should acknowledge receipt immediately and queue processing asynchronously, preventing timeouts if processing is slow. Deduplication prevents double-processing if the same webhook is received multiple times. Audit logging tracks all incoming webhooks, when they were received, and how they were processed.
Credential Management and Security
Integration Hub credentials (API keys, OAuth tokens, passwords) must be stored securely and accessed safely. ServiceNow credential storage encrypts credentials at rest. When a spoke or integration needs a credential, it retrieves it from secure storage, never embeds it in flow code or configuration files. Credential rotation (periodic changes to API keys or passwords) improves security and is easier to manage when credentials are centralized. Audit trails track credential access: who accessed what credential, when, and why. Segregating credentials by environment (dev, staging, production) prevents accidental use of production credentials during testing.
OAuth-based authentication is preferred over basic authentication when available: OAuth tokens are time-limited and scoped to specific permissions, reducing risk if a token is compromised. ServiceNow supports OAuth flows for systems that support it. Managing OAuth refresh tokens automatically prevents authorization failures when tokens expire.
Monitoring and Observability
Integration Hub provides operational visibility through logs and metrics. For each integration call, logs capture request details (what was requested, what parameters), response details (what was returned, how long did it take), and any errors. Slow integration calls are visible in logs; you can identify if an external system’s API performance is degrading. Failed calls are logged with error details: was it a connectivity issue, authentication failure, or application error? This information guides troubleshooting. Audit logs track who triggered an integration and when, providing compliance evidence.
Dashboards aggregate integration metrics: call volume, success rate, average latency, peak usage times. Alerts can notify operations if success rate drops (indicating the external system or integration is broken), if latency spikes (indicating performance problems), or if authentication failures occur (indicating credential issues). Some organizations integrate these metrics into IT operations dashboards alongside other system health metrics.
Dependency and Resilience
When ServiceNow depends on external systems via integrations, failures in external systems affect ServiceNow workflows. If a critical integration fails and no error handling is in place, the ServiceNow process grinds to a halt. Resilience patterns include: graceful degradation (the process continues with reduced functionality if the external system is unavailable), local caching (recently-retrieved data is cached and used if the external system is unavailable), and asynchronous processing (the integration call is queued for retry rather than blocking the current process). Choosing the right pattern depends on how critical the integration is and what’s an acceptable failure mode.
Vendor SLA awareness determines what level of reliability you should expect. If an external system publishes an uptime target, you should still expect short outages. Integration design should tolerate these outages. If you’re integrating with a system you control internally, you may have higher SLA expectations and design accordingly.
Testing and Deployment
Integration Hub integrations should be tested in staging against staging instances of external systems (if available) before deploying to production. Testing should cover happy paths (normal operation) and error scenarios (system unavailable, invalid credentials, slow responses, malformed data). Deployment should follow change control processes. Rollback plans should be in place in case an integration deployment causes problems. Monitoring in production immediately after deployment tracks whether the integration is working correctly, and alerts on any issues.
Choosing the call shape before choosing the connector
Many integration arguments are really arguments about shape. One side wants the ServiceNow record to wait until the external system confirms a change, the other wants the change to be sent and forgotten, and both are describing a real pattern with different costs. Settle the shape first, because it decides how errors come back, how long a user waits and what the recovery procedure looks like. The connector choice follows from it.
Four shapes cover most of the work. Synchronous request and reply keeps the flow waiting for an answer, which suits a lookup the user needs before the next step. Asynchronous submission sends the request and records a pending state, which suits anything that takes minutes at the external side. Inbound event handling receives a call from outside, which needs an endpoint that authenticates the sender and validates the payload before anything runs. Scheduled bulk transfer moves many records in one run, which suits reference data rather than live work.
A comparison of the four shapes
| Shape | Use it when | Typical failure | How recovery works |
|---|---|---|---|
| Synchronous request and reply | The next step needs the answer, such as a credit or eligibility check | The external system is slow, so the user waits and the request times out | Set a clear timeout, then route to a manual task with the request preserved |
| Asynchronous submission with a callback | The external job runs for a long time and the record can show a pending state | The callback never arrives, so the record sits in pending | A scheduled check finds records pending longer than the agreed window and raises them |
| Inbound event handling | An outside system needs to change a record in ServiceNow | Bad payloads or a sender that is not who it claims to be | Reject and log the payload, and never partially apply it |
| Scheduled bulk transfer | Large reference sets such as locations or cost centers change overnight | One bad row halts the run and nobody notices until the next morning | Process in batches with row-level error capture and a replay of failed rows |
An ordered procedure for choosing a shape
- Write down what the user or the next process does with the result, and how long they can wait for it.
- Find out how long the external operation takes in its worst normal case, not its average.
- Decide what the record should show while the external side is still working, and name the state.
- Define the recovery action for each failure, and who takes it.
- Only then pick the connector or the scripted call that implements the chosen shape.
Anti-patterns that look convenient
Chaining several synchronous calls inside a business rule is a common mistake. It works in a demonstration and fails under load, because each external delay holds a database transaction open while the user waits. Another is treating an inbound event as trusted because it came from a known address. Addresses can be shared or spoofed, so the handler should check the credential and the payload against an expected schema. A third is using a bulk transfer to carry work that a person is waiting on. A nightly run is the wrong answer to a question asked at lunchtime.
Signs the chosen shape is wrong
If support staff keep re-running a process by hand, the shape is probably too optimistic about the external side. If a pending state accumulates with no owner, the callback was designed without a timeout. If a bulk run regularly finishes with a long tail of failed rows that someone fixes by hand, the transfer was built as all-or-nothing when it should have been row-level. Each symptom points back to the shape decision rather than to the connector. The integration error handling notes explain how to give each of these failure states a documented owner.
Documenting the shape so the next team can read it
Record the chosen shape, the expected states of a record while work is in flight, and the owner of each recovery action in the integration’s design note. A new engineer should be able to tell from that note whether a stuck record is a timeout to retry or a message that was never sent, without opening the flow.
Questions about choosing between the common shapes
Is a webhook always better than polling?
No. A webhook needs an endpoint that the external system can reach and that authenticates the sender. Polling is simpler to restart after an outage and is sometimes the only option when the external system cannot call out at all. The choice depends on what the external system supports and how quickly the change is needed.
How long should a synchronous call be allowed to run?
Only as long as the user or the next step can reasonably wait. Set the timeout from that business requirement, then test it against the worst normal duration of the external operation, not its typical duration.
Can one flow combine synchronous and asynchronous steps?
Yes, and it is common: a quick synchronous eligibility check followed by an asynchronous submission for the slow work. Each step needs its own failure route, because a timeout at the first step and a missing callback at the second call for different recovery actions.
The ServiceNow integrations overview covers how ServiceNow connects to existing systems, and the blog article on REST integration design looks at the request and response decisions in more detail. The Integration Hub API automation service page describes how OBLYTECH approaches these designs.
Integration Hub or a point-to-point script: what a spoke changes
Integration Hub earns its place when more than one flow talks to the same outside system, when someone other than the original author will maintain the integration, or when credentials must differ between environments. A one-off scripted call from a single business rule to a single internal service is a reasonable point-to-point choice and does not need a spoke.
| Concern | Point-to-point script | Spoke action in a flow |
|---|---|---|
| Credentials | Held wherever the author chose to put them | Held in a connection and credential alias, so the flow is unchanged when the target moves from test to production |
| Reuse | Copied from script to script | One action called from many flows |
| Failure handling | Written again each time | Handled at the action, with the error visible in the flow execution record |
| Who can change it | Someone who can write script | Anyone who can edit a flow, within access controls |
Authentication is the part that brings many people to this topic, and a spoke does not make the outside system’s authentication simpler. It moves the decision to one place. Choose the method the external system offers, prefer a token that expires and carries limited permissions over a shared password, and set it up once on the alias. When the outside party rotates a key, one record changes instead of every script that used it.
Which spokes are available depends on the licence the organisation holds, so settle that before a design leans on a particular spoke. The licensing and cost factors guide lists the questions to answer first.
Where no spoke exists for the system, build a reusable custom action around the REST call rather than scripting it inline, so the next flow can use the same action. The REST and SOAP integrations guides cover the call itself, and the explanation of an action in Flow Designer shows how it is packaged.
Frequently asked questions
Should we use spoke connectors or custom REST integrations?
Always prefer spoke connectors when available. Spokes handle authentication, error cases, and common operations professionally. Custom REST integration requires more work, is harder to maintain as external APIs change, and is more likely to have security issues with credential handling. Only use custom integration when no spoke exists for your system, or when integration requirements are so specialized that the spoke doesn't support them.
What should we do if an external system that ServiceNow integrates with becomes unavailable?
Depends on what the integration does. For read-only integrations (retrieving data), graceful degradation works: show cached data or default values. For write operations, local queuing works: queue the changes to apply when the system recovers. For critical operations, you may need manual intervention: notify the user that the operation failed, let them retry manually when the external system recovers. The specific handling depends on business impact; it should be determined during integration design, not discovered when the external system fails.
How do we manage multiple integrations with the same external system?
Consolidate shared credential management: one credential is used by all integrations with the system. Have one person or team responsible for integration monitoring and troubleshooting. Coordinate upgrades and changes to the external system so all integrations are updated consistently. Using API rate-limiting to ensure one runaway integration doesn't consume all your API quota.
Related guides
Planning, running or fixing a ServiceNow programme? Tell us where you are and we will suggest a sensible next step.
Contact us