CAD Guide

IntegrationHub and Spokes

Introduction

IntegrationHub extends ServiceNow's Flow Designer with a library of pre-built integration components called Spokes. Where building a REST integration traditionally required scripting RESTMessageV2 calls and parsing responses, IntegrationHub wraps these into drag-and-drop Actions that non-developers can use in flows.


What Is a Spoke?

A Spoke is a packaged collection of Flow Designer Actions for a specific external system. Each Action represents a single operation:

Spoke Example Actions
Slack Send Message, Create Channel, Add Reaction
Jira Create Issue, Update Issue, Add Comment, Get Issue
Microsoft Teams Post Message, Create Meeting
AWS Start EC2 Instance, Get S3 Object, Invoke Lambda
Azure Create VM, Manage Resource Group
GitHub Create Issue, Merge Pull Request, Get Repository
Zoom Create Meeting, Get Recording
ServiceNow (internal) Create Record, Update Record, Ask For Approval

Spokes are installed from the ServiceNow App Store as plugins.


Using a Spoke Action in a Flow

Once a spoke is installed, its actions appear in the Action picker alongside native ServiceNow actions:

Flow Step → Add Action → Integrations → Slack → Send Message

Configuration:
  Channel: #major-incidents
  Message: "P1 Alert: " + [Trigger → Incident → Number] + 
           " | " + [Trigger → Incident → Short Description]
  Username: ServiceNow Bot

No scripting required — data pills connect the ServiceNow record data to the Slack message.


Connection Aliases

Spoke Actions use Connection Aliases to manage authentication credentials — keeping secrets out of flows:

System Web Services > REST > Connection Aliases

A Connection Alias stores:

  • Base URL of the target system
  • Authentication method (Basic, OAuth, API Key)
  • Credentials (stored as encrypted Credential records)

Flows reference the alias by name. Changing the alias updates all flows that use it — ideal for environment migration (dev → prod).


Building a Custom Spoke

For proprietary internal systems without a pre-built spoke:

Step 1: Create a Custom Action

Flow Designer → New → Action

Step 2: Add a REST Step

Inside the Action, add a REST Step:

Action Step: REST
  Connection: [Your Connection Alias]
  Method: POST
  Relative URL: /api/v1/tickets
  Request Body:
    {
      "title": "${inputs.title}",
      "priority": "${inputs.priority}",
      "external_ref": "${inputs.external_ref}"
    }

Step 3: Parse the Response

Add a Script Step after REST to parse the response and set outputs:

(function execute(inputs, outputs) {
    var response = JSON.parse(inputs.rest_response_body);
    outputs.ticket_id = response.id;
    outputs.ticket_url = response.url;
})(inputs, outputs);

Step 4: Define Inputs and Outputs

Inputs:

  • title (String)
  • priority (String)
  • external_ref (String)

Outputs:

  • ticket_id (String)
  • ticket_url (String)

Publish the Action. It now appears in the Action picker for any Flow Designer user.


Spoke vs. Manual RESTMessageV2

Approach When to Use
Pre-built Spoke Target system has a published spoke
Custom Spoke (Action) Reusable integration used in multiple flows
RESTMessageV2 in script One-off integration in a Business Rule/Scheduled Job
RESTMessageV2 + REST Message record Complex outbound integrations with retry logic

For any integration that will appear in flows, prefer Spoke Actions — they're maintainable by admins without scripting knowledge.


Error Handling with Spokes

Spoke Actions expose HTTP status codes as outputs. Handle errors in flows:

[Jira: Create Issue]
  ↓
[If: HTTP Status Code is NOT 201]
  → [Log Error]
  → [Send notification to integration team]
  → [Update ServiceNow record with failed state]

Best Practices

  • Use Connection Aliases for all spoke configurations — never hardcode credentials
  • Create one Connection Alias per environment (dev, prod) for easy migration
  • Test spoke actions against sandbox/test instances of external systems first
  • Build custom Actions for any integration used more than once
  • Document custom spoke inputs/outputs in the Action description field
  • Monitor flow execution logs to catch spoke failures early
  • Use specific, scoped roles to restrict which flows can use sensitive spokes

Conclusion

IntegrationHub changes the economics of integration work. What once required a developer writing RESTMessageV2 scripts, error handling, and retry logic can now be a five-minute drag-and-drop configuration. Pre-built spokes cover most common enterprise systems, and the custom Action builder handles the rest. Invest in building your organization's spoke library, and every future integration becomes faster and more consistent.

Keep reading this guide

Log in to access the full study guide and supercharge your preparation.