IntegrationHub in ServiceNow: Using Spokes to Connect External Systems in Flow Designer

What is a spoke?

A spoke is a bundled set of Flow Designer actions for a specific external system or service. Each action handles a specific operation — "Post Message to Slack", "Create Issue in Jira", "Send Teams notification". The spoke handles the HTTP calls, authentication, retry logic, and error handling automatically — you just provide the parameters.

Common spokes

• Slack — post messages, create channels, invite users, manage conversations
• Microsoft Teams — post messages, create meetings, manage channels
• Jira — create/update/transition issues, add comments, manage projects
• ServiceNow — create/update records across ServiceNow instances
• GitHub/GitLab — create issues, PRs, manage repositories
• Email — send formatted emails with attachments
• REST — generic spoke for any REST API with no dedicated spoke
• SOAP — generic spoke for SOAP/WSDL services

The REST spoke — for any API

When there is no dedicated spoke for a system, the REST spoke handles any HTTP API. In a Flow Designer action step:

1. Add Action > REST > REST Step
2. Set the Connection (Connection Alias — see Credential Aliases guide)
3. Configure: method, URL path, headers, request body
4. Map response fields to output variables using data pills

// REST Spoke step configuration:
// Connection: my-external-api (Connection Alias name)
// HTTP Method: POST
// URL Path: /v1/incidents
// Request Body (JSON):
{
  "title": "${trigger.incident.short_description}",
  "priority": "${trigger.incident.priority}",
  "reference": "${trigger.incident.number}"
}
// Output: Response Body → parse with Script step

Setting up credentials for spokes

All spokes use Connection and Credential Aliases to store authentication securely. Navigate to the spoke's configuration page in Flow Designer and create a new connection — it links to the Credential Alias where the actual token or password is stored. Never enter credentials directly into flow variable values.

Error handling with spoke actions

Always wrap spoke actions in Try/Catch steps. HTTP calls fail — network issues, authentication expiry, rate limits, service outages. A flow that sends notifications to 200 users and fails on the 50th due to rate limiting needs a Catch block to handle the failure gracefully. See the error handling guide for retry patterns.

When to use a spoke vs RESTMessageV2

Use spokes when building in Flow Designer and a spoke exists for the system — they are faster to configure and maintainable by non-developers. Use RESTMessageV2 when: you need programmatic control from a Script Include, the integration logic is complex, or you are building a reusable integration library for other scripts to call.

Related: Error handling · Credential Aliases · RESTMessageV2 · MID Server

How IntegrationHub spokes work technically

An IntegrationHub spoke is a scoped application that packages a set of Flow Designer Action Steps for a specific external service. When you add a Slack spoke to a flow, you are using Action Steps from the Slack spoke application — each step encapsulates the API call, authentication handling, and parameter mapping. Spokes use Connection and Credential Aliases to store API keys and OAuth tokens securely, so the same spoke action works across environments (dev, test, prod) by pointing at different alias records rather than different hardcoded credentials.

Installing and activating spokes

Spokes are installed from the ServiceNow Store or from System Applications > All Available Applications. Search for the spoke by service name (e.g. "Jira Spoke", "Salesforce Spoke", "Microsoft Teams Spoke"). After installation, configure the Connection Alias record with the API credentials for your target system. Navigate to Connections & Credentials > Aliases to create or update the alias. Once the alias is configured, the spoke's action steps become available in Flow Designer's Action picker when building flows.

When to use a spoke vs a custom RESTMessageV2 call

Use a spoke when: one exists for the target system, your use case matches the available spoke actions, and IntegrationHub is licensed on your instance. Use RESTMessageV2 directly when: no spoke exists for the target system, you need custom API behaviour that the spoke does not expose, or you are building a Script Include integration library rather than a Flow Designer flow. For complex integrations that mix Flow Designer orchestration with custom scripting, a spoke for standard operations combined with a Custom Action (a Flow Designer step backed by a Script Include) for custom logic is often the cleanest architecture.

// Custom Action in Flow Designer — Script Include backed
// Useful for spoke-like behaviour without a published spoke
var IntegrationUtils = new x_myapp.IntegrationUtils();
var result = IntegrationUtils.callCustomAPI({
    endpoint: inputs.endpoint,
    payload: inputs.payload,
    method: 'POST'
});
outputs.response_code = result.statusCode;
outputs.response_body = result.body;

Related: RESTMessageV2 · Credential Aliases · Flow Designer · OAuth 2.0 · HTTP status codes

Licensing considerations

IntegrationHub is a separately licensed add-on to the base ServiceNow platform. The licensing tiers determine which spokes are available and how many "actions" (spoke step executions) are included. The Starter tier includes basic HTTP spoke and a small action count. Professional and Enterprise tiers add pre-built spokes for major enterprise systems (Salesforce, Jira, SAP, Workday) and substantially larger action volumes. Check your contract to verify what is licensed before designing integrations that depend on specific spokes — using a spoke your instance is not licensed for will fail silently or throw activation errors when you try to include it in a flow.

If IntegrationHub is not licensed or a specific spoke is not available, the alternative is a Custom Action (a Flow Designer step backed by a Script Include) that calls the external API via RESTMessageV2. This achieves the same result as a spoke action but requires writing the API call code rather than configuring it through the spoke UI. For one-off integrations, this is often the right trade-off even when IntegrationHub is available — spoke configuration is faster for standard operations, custom scripts are more flexible for custom requirements.

Debugging spoke failures in Flow Designer

When a flow fails on a spoke step, open the Flow execution record (All Flows > the specific flow > Executions) to see the step-by-step execution log. Each step shows its input, output, and error if it failed. Spoke failures typically fall into: credential errors (Connection Alias not configured correctly), API errors from the target system (the external API returned a non-success status), or network errors (the target system is unreachable from the ServiceNow cloud, which may require a MID Server for internal systems). The execution log gives you enough detail to distinguish these cases and direct your debugging accordingly.

Building a custom spoke for internal tools

For internal tools that need repeated integration across multiple flows — an internal ticketing system, a company-specific API, an internal approval engine — building a custom spoke is more maintainable than repeating RESTMessageV2 calls in every flow that needs the integration. A custom spoke is a scoped application containing Custom Action Steps: each action step handles one API operation (create ticket, get ticket status, update ticket) with a clean input/output interface. Once built, teams consuming the integration use the spoke action in their flows without knowing the underlying API details. Update the spoke when the API changes and every flow using it automatically gets the fix. This is the pattern used by ServiceNow's own published spokes and is appropriate for any integration used in more than two or three flows.