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.