The IntegrationHub instance ships with 200+ actions across spokes, the team built another 40 custom actions over two years, and nobody could draw the dependency map between them. Each integration broke independently in different ways — credentials, rate limits, schema drift, version pinning — and the on-call rotation kept getting paged. IntegrationHub’s value depends on the practices below; without them, every integration is its own reliability problem.
What IntegrationHub Actually Is
IntegrationHub is the layer Flow Designer (and Workflow Studio) uses to call outside systems. At its simplest, an action wraps a REST or SOAP call with typed inputs, typed outputs, and credential handling. Spokes are packages of related actions — Microsoft Teams Spoke, Slack Spoke, Salesforce Spoke, ServiceNow’s own internal spokes for cross-instance calls. The platform maintains the spokes against vendor API changes; custom actions are your responsibility forever.
You can build your own spoke or compose one-off actions inline in a flow. Both approaches are valid; choose based on reuse — if the same call appears in multiple flows, package it as a spoke action.
IntegrationHub structure:
Spoke (e.g., MicrosoftGraphSpoke)
-> Action (e.g., SendChannelMessage)
-> typed inputs (channel_id, message_body, mentions)
-> typed outputs (message_id, sent_timestamp)
-> credential alias (graph_app_credential)
-> error mappingCredentials First
The first thing to set up for any integration is the credential alias. OAuth 2.0, basic auth, JWT bearer, mutual TLS, AWS signing v4 — all supported. Centralize credentials in the credential store so rotating a secret is one place, not 20 hardcoded spots in scripts and connection records. Always test credentials with a simple read call before building out the flow; credential mistakes diagnosed against a complex flow waste hours.
// Pattern: credential alias referenced by name
var connection = sn_ih.RESTMessageV2.fromCredentialAlias('msgraph_prod');
connection.setEndpoint('https://graph.microsoft.com/v1.0/users');
var response = connection.execute();Use Transform Steps Sparingly
IntegrationHub has data transform steps that map one shape to another. Useful for non-trivial reshaping or when the same transform is needed across multiple flows. For simple field-to-field mapping, transform inline in the flow with Assign or Set Field Values. Too many transform steps create a maze of artifacts that future maintainers cannot trace through. Prefer inline assignment for simple cases; reserve transform steps for genuinely complex restructuring.
Rate Limits Are Real
External APIs rate-limit you, often aggressively under load. Most spokes do not handle 429 gracefully by default — they fail the action and the flow either errors or retries naively. Build a retry-with-exponential-backoff pattern once, put it in a subflow, and call it everywhere you hit a third party. Respect the Retry-After header when present; do not implement your own backoff curve when the API tells you exactly how long to wait.
// Retry-with-backoff helper (conceptual)
function callWithBackoff(callFn, maxRetries) {
for (var i = 0; i < maxRetries; i++) {
var response = callFn();
if (response.status !== 429) return response;
var waitMs = parseInt(response.headers['Retry-After']) * 1000 || (Math.pow(2, i) * 1000);
gs.sleep(waitMs);
}
throw new Error('Rate limit exceeded after '+maxRetries+' retries');
}Versioning a Custom Spoke
Custom spokes are applications and deserve app-lifecycle discipline. Version-control them via update sets or scoped app repositories, semver the spoke (major.minor.patch), and maintain a changelog. Breaking changes to an action signature cascade to every flow that uses it; bump the major version and provide a deprecation period for the old signature. Spokes without versioning are the most reliable source of “the integration broke after the platform update” tickets.
Common Failure Modes
Custom action that calls an endpoint synchronously without timeout — a slow third party blocks the flow indefinitely; always set explicit timeouts. Action with credentials inline rather than via alias — rotation requires touching every action. Spoke action that swallows error responses and returns success — the flow continues happily on a failed call; map errors explicitly. Flow that calls a spoke action in a loop without rate-limit awareness — produces a self-DoS against the third party.
What Changed in 2026
Workflow Studio is the strategic flow authoring surface. New custom spoke development should consider how actions surface in Workflow Studio (most do automatically; some custom UI-rendered actions need updates). The Microsoft Graph spoke and other major spokes have updated coverage in 2026 releases; review the release notes for spoke deltas relevant to your integrations.
Cost Considerations
IntegrationHub transactions are metered against your platform allowance. Heavy integrations (high-volume, high-frequency) can consume meaningful transaction budget. Monitor transaction usage per integration and per spoke; the dashboard surfaces top consumers. Optimize hot integrations to batch where possible (one call with 50 records beats 50 calls with one record each) and to skip unnecessary transactions (do not poll if the source supports webhooks).
Implementation Sequence
For new integrations, set up the credential alias first, test it, then build a single happy-path action, test it, then add error handling and retry logic, then wire it into a flow. The temptation to build the full integration in one sitting produces integrations that work in dev and fail in production with no obvious diagnosis. Test each layer before adding the next.
What to do this week: list every active integration in your instance and identify which call third-party APIs without retry-with-backoff handling — that list is your reliability backlog.
