ServiceNow Integration Hub Best Practices

Understanding Integration Hub and Spoke Selection

Integration Hub in ServiceNow provides connectors called spokes that integrate ServiceNow with external systems. Each spoke handles a specific type of connection: REST API spokes, database spokes, email spokes, and hundreds of vendor-specific spokes. Selecting the right spoke and configuring it correctly is essential for reliable integrations. This section covers best practices for spoke selection, configuration, and ongoing operations.

Spoke Selection and Vendor-Specific Connectors

When integrating with an external system, first check whether ServiceNow offers a vendor-specific spoke. ServiceNow maintains spokes for popular platforms like Salesforce, Workday, Slack, and others. Vendor-specific spokes are preferable to generic REST spokes because they handle vendor-specific authentication, data mapping, and error handling. Using a vendor spoke reduces your implementation time and risk.

If no vendor spoke exists, use a generic REST spoke to call the vendor’s APIs. REST spokes require more configuration: you must handle authentication (OAuth, API key, basic auth), construct request payloads, and parse responses. Document the vendor’s API documentation, understand rate limits, and plan for API changes when the vendor updates their platform.

Decisions: should you use the vendor spoke or build a REST integration? Vendor spokes are simpler and more maintainable. REST integrations offer more flexibility if the vendor spoke does not support all the operations you need. Evaluate based on the specific use case.

Error Handling and Resilience

Integrations fail. Network timeouts occur, external systems go down, data validation fails, or rate limits are exceeded. Design integrations with failure handling from the start. Every integration should have retry logic: if a call to an external system times out, retry after a delay. Most integrations should retry at least twice with exponential backoff (wait 1 second, then 10 seconds, then 100 seconds) before giving up.

Define what happens when an integration fails. Should the workflow stop and alert an operator? Should it queue the message for retry? Should it create a ticket for manual resolution? Document the failure handling for each integration so support teams know what to do when integrations fail.

Graceful degradation: some integrations are critical (must succeed or the workflow fails); others are optional (if the integration fails, the workflow continues with degraded functionality). Design each integration knowing whether it is critical or optional.

Error logging: Integration Hub logs all API calls and responses. Configure logging to capture request, response, and error details. Retention policy: how long do you keep logs? Longer retention helps troubleshooting but costs storage. Set the retention period to fit troubleshooting needs and storage cost.

Authentication and Security

Integrations must authenticate with external systems. Never hardcode credentials in integration configurations or scripts. Use ServiceNow Credentials (stored in the Connections table) to securely store API keys, usernames, passwords, and OAuth tokens. Credentials are encrypted and accessed only by authorized service accounts.

Credential rotation: OAuth tokens expire and must be refreshed. Many API keys should be rotated periodically for security. Set up a process for credential rotation: update credentials in ServiceNow at least annually and immediately if a breach is suspected. Document which system owns each credential and who is responsible for rotation.

Rate limiting: many APIs have rate limits (e.g., 100 calls per minute). Design integrations to respect rate limits. Use Integration Hub throttling features to control call rate. If you exceed a vendor’s rate limit, the vendor will reject calls. Design retry logic that backs off when rate limits are exceeded.

Monitoring and Alerting

Set up monitoring for all integrations. Monitor for: successful calls versus failures; API response times; rate limit errors; authentication failures; and data validation errors. Create dashboards showing integration health and performance. Alert your team if integration failure rate exceeds a threshold (for example, more than a small fraction of calls failing) or if response time exceeds a target.

Implement a runbook for common integration failures: what does it mean if an integration times out? What is the recovery action? Document these so your support team can respond quickly.

Testing: integration testing must include failure scenarios. Test what happens when the external system is down, when APIs return errors, when rate limits are exceeded, and when network latency is high. Test with realistic data volumes.

Data Validation and Data Quality

Integrations often transform data from one system to another. Validate data before sending it to an external system. For example, if you are sending an employee record to a payroll system, validate that required fields are populated and that data formats are correct (dates in the expected format, numeric fields actually contain numbers).

Handle data mismatches: what if the external system’s data types or formats differ from ServiceNow? Design transformations that handle these differences. For example, if the vendor system uses a different date format, transform ServiceNow dates to the vendor format before sending.

Exception handling: when data validation fails, what should happen? Should the record be rejected and manually reviewed? Should it be transformed to a safe default? Different use cases require different approaches. Document data validation rules and exception handling for each integration.

Scaling Integrations for Enterprise

As integrations grow in volume (more records, more calls), performance becomes critical. Monitor integration throughput and latency. If an integration processes 100 records per day but you scale to 10,000 records per day, response time will degrade unless you optimize.

Optimization strategies: batch API calls where possible (send multiple records in one API call instead of one record per call); use asynchronous patterns instead of synchronous (submit a batch job rather than wait for each record); use webhooks for real-time events instead of polling.

Distributed processing: if a single Integration Hub instance cannot handle the load, configure multiple instances or use event-driven patterns. ServiceNow supports scaling integrations through different architectural approaches.

Documentation and Handover

Document each integration: which systems are connected, what data flows in which direction, the error handling and retry logic, monitoring and alerting setup, credentials and authentication method, and runbooks for common issues. This documentation is essential for operational support and future enhancement. When the integration is handed over to operations, operations teams must be trained on the integration and have clear documentation to reference.

Deciding whether a working spoke should be patched, replaced or retired

The practices in the sections above mostly assume that an integration is being built. A harder problem appears a year later, when a spoke that once worked starts to fail in ways its original author no longer understands. The vendor has changed an endpoint, a field has been renamed, or the volume has grown many times over since the design was signed off. At that point the platform team has three options: patch the existing flow, rebuild the connection on a different mechanism, or retire the integration and move the work somewhere else. Treating all three as the same kind of fix is a common reason a fragile integration stays in production for years.

A decision table for the three options

A checklist before patching a spoke that is already in production

1. Reproduce the failure in a non-production instance using a copy of the request and response that failed. Do not debug against live credentials.
2. Read the execution history for the same flow across the period before the failure, not just the failed run, to see whether the change is sudden or a slow drift.
3. Check the credential alias that the flow uses and confirm it still points to the intended account and scope.
4. Confirm which other flows share the same connection so that a change does not break an unrelated process.
5. Write the fix as a small, reviewable change with a note of what the vendor changed, and keep the prior version on hand so a rollback stays possible.

Signs that a spoke has outgrown its design

Watch for work that needs manual restarts, retries that succeed only after an operator touches the record, and flows whose error branch has grown longer than the happy path. Each of these suggests that the design assumed a volume, a timing pattern or a vendor behavior that no longer holds. One practical check is whether a newcomer could explain the flow to an auditor without reading the original author’s notes. If the answer is no, the spoke needs redesign before the next change request arrives.

When Integration Hub is not the right tool at all

Integration Hub suits event-driven and orchestrated calls to external services. It is a poor place to move large reference datasets in one pass. For that work, an import set with transform maps or a scheduled data job often gives clearer error reporting, easier replay and simpler reconciliation. A mismatch like this often does not show on the first day. It shows when the data volume doubles and the team discovers that a per-record design has no practical way to restart from the middle of a batch.

How to tell the practice is holding

Good operating practice shows up as fewer surprises, not as more dashboards. Track how often a spoke needed an unplanned change in the last quarter, how many of those changes were caused by the vendor and how many by internal edits, and whether the runbook matched what the on-call person actually did. A spoke that is changed often by the same people for the same reason is a candidate for replacement, even if every individual fix worked. Pair that review with the integration error handling patterns so that each new failure class gets a documented response rather than an ad hoc one.

Practical questions about running spokes over time

Is it acceptable to switch off retries on a noisy spoke?

Only after the cause is known. Disabling retries hides transient faults and pushes them onto people who then chase records by hand. Cap the retry count, keep the backoff, and make sure the final failure lands in a route with an owner.

Who should keep the credential rotation calendar?

The connection owner should hold the calendar and the platform operator should carry out the change. Put the rotation date in the same register entry as the connection so that the date is visible to whoever is on call.

Does every spoke need its own test instance?

Not necessarily. A shared non-production instance is common, provided the credentials it holds point to test accounts at the vendor. What matters is that a change is proven against a copy of the request that failed before it reaches production.

For a broader view of the usual failure patterns, the Integration Hub troubleshooting guide sets out how to narrow down a failing flow, and the Integration Hub health check page describes how a structured review of spokes already in production is set up.