IntegrationHub

What It Is

IntegrationHub is ServiceNow's native integration platform that provides pre-built connection packs called Spokes for integrating with external systems like Jira, Slack, AWS, Salesforce, and hundreds of other applications. It eliminates the need to write custom REST messages, SOAP messages, or complex authentication scripts by providing drag-and-drop actions that handle the underlying API calls, authentication protocols, and data transformations. The platform operates as a visual workflow designer where you build integration flows using a combination of core Flow Designer actions and Spoke-specific actions that represent real operations in target systems—creating tickets, sending messages, provisioning resources, or querying data.

Architecturally, IntegrationHub sits within the Flow Designer framework under the Process Automation application scope and extends the core Flow Designer engine with external connectivity capabilities. Each Spoke is packaged as a scoped application that contains connection configurations, credential management, action definitions, and supporting script includes that handle the actual API integrations. The execution happens within the Flow Designer runtime environment, which means IntegrationHub flows inherit all the same execution context, logging, error handling, and performance characteristics as standard flows.

The data model revolves around three core tables: sys_hub_action_type_base which defines the available actions from each Spoke, sys_hub_connection which stores connection configurations and credentials for external systems, and wf_workflow_version which contains the actual flow definitions where IntegrationHub actions are used. When a flow executes, the Flow Designer engine reads the action configuration, retrieves the associated connection record, and passes both to the Spoke's action script which handles the external system interaction.

You cannot function without IntegrationHub when you need reliable, maintainable integrations with popular SaaS platforms that require complex authentication like OAuth 2.0, certificate-based authentication, or dynamic token refresh mechanisms. Custom REST messages break when APIs change, require manual credential management, and provide no built-in error handling or retry logic—IntegrationHub Spokes handle all of this automatically and get updated by ServiceNow when target system APIs evolve. The platform becomes essential for organizations running hybrid environments where ServiceNow needs to orchestrate processes across multiple systems, trigger actions in response to ServiceNow events, or synchronize data between ServiceNow and external platforms without building custom middleware.

Platform owners typically handle IntegrationHub licensing and Spoke installation decisions since each active Spoke counts against your IntegrationHub license allocation. ServiceNow administrators manage connection configurations, credential storage, and flow development using the pre-built actions, while developers extend IntegrationHub by creating custom Spokes when no pre-built option exists for their target system. The role separation matters because connection configurations often contain sensitive credentials that require admin-level access, while flow development can be delegated to process owners who understand the business logic but don't need system-level privileges.

Recent releases have significantly improved IntegrationHub's development experience and performance. Vancouver introduced the ability to test Spoke actions directly from Flow Designer without building a complete flow, which dramatically speeds up connection troubleshooting and action configuration. Xanadu added enhanced error handling and retry capabilities at the Spoke level, plus improved credential encryption for connections. The Washington release brought better integration with App Engine Studio, allowing citizen developers to use IntegrationHub actions in their custom applications without needing to understand Flow Designer complexity.

Where to Find and Configure It

Navigate to Process Automation > IntegrationHub > Spokes to browse available Spokes and install new ones from the ServiceNow Store. Go to Process Automation > IntegrationHub > Connections to configure authentication and connection details for your external systems. Access Process Automation > Flow Designer to build flows that use IntegrationHub actions.

Within Flow Designer, IntegrationHub actions appear in the Action palette under their respective Spoke names when you're building or editing a flow. Check System Applications > My Company Applications to see installed Spoke applications and their version information. View execution logs and troubleshoot integration issues at Process Automation > Flow Designer > Execution Details where IntegrationHub actions show detailed request/response information for each external system call.

For advanced configuration, access System Definition > Tables and search for sys_hub to see the underlying connection and action configuration tables. Within Studio, navigate to any installed Spoke application to examine or modify action definitions, though this requires developer access and should be done carefully to avoid breaking existing integrations. IntegrationHub works the same way in both scoped and global applications—the key difference is that connections created in scoped applications are only accessible to flows within that same scope unless explicitly shared.

How It Works Step by Step

IntegrationHub operates within Flow Designer's execution engine, where each Spoke action is essentially a specialized script include that knows how to communicate with a specific external system. When you configure a Spoke action in a flow, you're setting up the input parameters and selecting a connection record that contains the authentication details and endpoint information for your target system. The action configuration gets stored as part of the flow definition, while the sensitive connection details remain separate in the connection record for security and reusability.

During execution, Flow Designer processes each action sequentially according to your flow logic, passing data between actions through the execution context. When it reaches an IntegrationHub action, the Flow Designer engine calls the action's script include, which retrieves the connection configuration, handles authentication (including token refresh if needed), constructs the appropriate API request, and sends it to the external system. The action script processes the response, handles any errors according to the Spoke's built-in logic, and returns structured data that subsequent flow actions can use.

The connection records are cached during flow execution to avoid repeated database queries, and authentication tokens are cached according to each system's token lifecycle requirements. If an action fails due to authentication issues, the Spoke automatically attempts to refresh credentials and retry the operation once before reporting a failure. All requests and responses are logged to the Flow execution details for troubleshooting, but sensitive authentication data is redacted from the logs for security.

The Execution Order

1. Flow Designer trigger fires and creates execution context with trigger data
2. Flow engine processes actions sequentially until it reaches an IntegrationHub action
3. Action script retrieves connection record from sys_hub_connection table using configured connection reference
4. Spoke validates authentication credentials and refreshes tokens if necessary
5. Action constructs API request using input parameters and connection endpoint details
6. HTTP request sent to external system with proper headers and authentication
7. Response processed and transformed into structured data according to Spoke's response mapping
8. Success or error data returned to Flow Designer execution context for use by subsequent actions

// Example Spoke action script pattern for Slack integration
(function execute(inputs, outputs) {
    var connection = inputs.connection;
    var channel = inputs.channel;
    var messageText = inputs.message;
    
    // Get connection details
    var conn = new sn_hub.Connection(connection);
    var token = conn.getToken();
    var baseUrl = conn.getEndpoint();
    
    // Construct request
    var request = new sn_ws.RESTMessageV2();
    request.setEndpoint(baseUrl + '/api/chat.postMessage');
    request.setHttpMethod('POST');
    request.setRequestHeader('Authorization', 'Bearer ' + token);
    request.setRequestHeader('Content-Type', 'application/json');
    
    var payload = {
        'channel': channel,
        'text': messageText
    };
    request.setRequestBody(JSON.stringify(payload));
    
    // Execute and handle response
    var response = request.execute();
    if (response.getStatusCode() == 200) {
        var responseBody = JSON.parse(response.getBody());
        outputs.message_ts = responseBody.ts;
        outputs.success = true;
    } else {
        outputs.error_message = response.getErrorMessage();
        outputs.success = false;
    }
})(inputs, outputs);

Real-World Scenarios

Auto-Creating Jira Issues from Critical ServiceNow Incidents

Your development team uses Jira for tracking work but critical production incidents start in ServiceNow. When a Priority 1 or Priority 2 incident gets created, you need to automatically create a corresponding Jira issue in the appropriate project and link it back to the ServiceNow incident for tracking.

Install the Jira Spoke from Process Automation > IntegrationHub > Spokes, then create a connection at Process Automation > IntegrationHub > Connections using your Jira instance URL and API token. Build a flow triggered by Incident - created with a condition checking if Priority is 1 - Critical or 2 - High. Add the Jira - Create Issue action, mapping ServiceNow incident fields to Jira issue fields—short description becomes summary, description maps to description, and priority translates appropriately. Follow up with an Update Record action to store the Jira issue key in a custom field on the incident record.

Watch for Jira project permissions—your API token needs create issue permissions in the target project, and the issue type you're creating must be available in that project's configuration. Set up proper error handling in your flow because Jira API calls can fail due to field validation, missing required fields, or permission issues. Consider adding a retry mechanism for transient network failures, and always test with non-production Jira projects first to avoid creating test issues in live development boards.

Slack Notifications for Change Approval Workflow

Your change advisory board (CAB) members work primarily in Slack and need immediate notification when emergency changes require approval. The notification should include change details and direct links back to ServiceNow for quick approval actions.

Create a Slack connection using a bot token with chat:write permissions and add the bot to your CAB channel. Build a flow triggered by Change Request - created with a condition for Type equals Emergency. Use the Slack - Send Message action with a formatted message containing change number, short description, planned start/end times, and a direct link to the change record using the instance's base URL plus the change number. Include @channel mention to ensure immediate visibility, and format the message using Slack's block kit for better readability.

Be careful with @channel mentions in high-volume channels—consider using @here instead or targeting specific user groups. Test your Slack connection thoroughly because bot permissions can change without warning if workspace admins modify security settings. The ServiceNow URL in messages needs to account for different user authentication methods—some users might access through SSO portals rather than direct instance URLs, so document the correct access method for your CAB members.

AWS EC2 Instance Provisioning from Service Catalog

Your service catalog includes a VM provisioning item that should create actual AWS EC2 instances when users submit requests. The flow needs to handle the EC2 creation, wait for the instance to be running, and update the ServiceNow request with connection details.

Set up an AWS connection using IAM credentials with ec2:RunInstances, ec2:DescribeInstances, and ec2:CreateTags permissions. Create a flow triggered by Service Catalog - Request Approved with a condition checking for your VM catalog item. Use AWS EC2 - Launch Instance action, mapping catalog variables to EC2 parameters like instance type, AMI ID, security group, and subnet. Add a Wait for Condition action that polls AWS EC2 - Describe Instance until the instance state equals 'running', then update the request item with the instance ID and IP address.

AWS API calls can fail for quota limits, invalid parameter combinations, or insufficient permissions—build comprehensive error handling that updates the ServiceNow request with meaningful failure messages rather than technical error codes. The wait condition needs a reasonable timeout (5-10 minutes) because EC2 instance launches can take several minutes depending on the AMI and instance type. Store the AWS region in your connection configuration and ensure your AMI IDs, security groups, and subnets exist in that specific region, as these resources are region-specific in AWS.

The Classic Mistake

The most devastating mistake is calling IntegrationHub actions synchronously from business rules, especially on high-volume tables like incident or task. Admins typically set up a business rule on the Incident table with When: after and Insert: true, then directly invoke something like a Slack notification action using sn_ih.IntegrationHub.runAction() without any try-catch blocks. When Slack's API is down or times out, the entire incident creation fails, the transaction rolls back, and users see cryptic "Database operation failed" errors. This happens because ServiceNow treats the external API call as part of the same database transaction, and any uncaught exception during the action execution causes the entire transaction to abort.

// Business Rule - After Insert on Incident
// This will break incident creation when Slack is down

(function executeRule(current, previous /*null when async*/) {
    
    var actionName = 'sn_slack.post_message';
    var inputs = {
        'channel': '#incidents',
        'text': 'New incident: ' + current.short_description,
        'username': 'ServiceNow'
    };
    
    // WRONG: Synchronous call with no error handling
    var result = sn_ih.IntegrationHub.runAction(actionName, inputs);
    
    gs.info('Slack message sent for incident: ' + current.number);
    
})(current, previous);

This fails because IntegrationHub actions have their own timeout settings (typically 30-60 seconds), and when external APIs are slow or unavailable, the business rule execution hangs until timeout, then throws an exception that kills the parent transaction. Users see "Error inserting record" messages instead of their incident being created, and the Slack notification becomes more important than the actual business process. ServiceNow's transaction isolation means that if any part of the transaction fails, everything rolls back, including the incident record that triggered the integration.

// Business Rule - After Insert on Incident
// Resilient pattern that doesn't break incident creation

(function executeRule(current, previous /*null when async*/) {
    
    try {
        var actionName = 'sn_slack.post_message';
        var inputs = {
            'channel': '#incidents',
            'text': 'New incident: ' + current.short_description,
            'username': 'ServiceNow'
        };
        
        // CORRECT: Asynchronous execution with error handling
        sn_ih.IntegrationHub.runActionAsync(actionName, inputs, function(result) {
            if (result.getStatus() === 'success') {
                gs.info('Slack notification sent for: ' + current.number);
            } else {
                gs.error('Slack notification failed: ' + result.getErrorMessage());
            }
        });
        
    } catch (ex) {
        gs.error('IntegrationHub action setup failed: ' + ex.message);
        // Incident creation continues regardless
    }
    
})(current, previous);

When to Use This vs Alternatives

IntegrationHub is the right choice when you need reliable, auditable integrations with popular enterprise applications and can leverage pre-built Spokes. The platform handles authentication, error handling, and logging automatically, making it ideal for organizations that want integration capabilities without extensive custom development. Use IntegrationHub when you're integrating with systems like Jira, Slack, AWS, Azure, or Salesforce where ServiceNow already provides certified Spokes.

Choose IntegrationHub When You Need Governance

IntegrationHub provides built-in credential management, execution tracking, and approval workflows that custom REST Message calls and scripts cannot match. When compliance, auditability, and non-developer maintenance are priorities, IntegrationHub beats custom integration scripts every time. The platform automatically logs all action executions in sys_hub_action_status and provides visual Flow Designer integration that business analysts can understand and modify.

Use REST Messages for Custom APIs

When integrating with proprietary systems, internal APIs, or when you need fine-grained control over HTTP headers, authentication methods, or response parsing, use REST Messages instead. IntegrationHub Spokes are opinionated and may not support every API endpoint or authentication scheme your custom application requires. For high-frequency, low-latency integrations where every millisecond matters, direct REST Message calls from server-side scripts will always outperform IntegrationHub's action framework.

Combine Both for Hybrid Architectures

Use IntegrationHub for standard operations (creating Jira tickets, sending Slack messages, provisioning cloud resources) and REST Messages for custom endpoints within the same integration pattern. A common architecture uses IntegrationHub actions in Flow Designer for business user-facing automations, while background processes and bulk data synchronization rely on scheduled scripts with REST Messages. This gives you the governance benefits of IntegrationHub where users interact with it, and the performance benefits of direct API calls where speed matters most.

Platform Interactions & Side Effects

• Every IntegrationHub action execution creates records in sys_hub_action_status and sys_hub_step_status, including full input/output payloads, which can consume significant database space in high-volume environments
• Update Sets capture IntegrationHub Spoke installations but not credential configurations, meaning spoke updates can break existing flows when promoted between instances without credential reconfiguration
• Flow Designer flows calling IntegrationHub actions bypass normal Business Rules and ACL enforcement on the source record, potentially allowing data access that the flow's execution user shouldn't have
• Credential records in discovery_credentials are encrypted but visible to users with credentials_admin role, creating potential security exposure if role assignments aren't carefully managed
• IntegrationHub actions running asynchronously create separate transaction scopes, meaning current.update() calls within action scripts don't affect the triggering record's transaction
• Email notifications triggered by IntegrationHub record updates can create infinite loops if the notification itself triggers flows that call more IntegrationHub actions
• System property com.snc.integration_hub.worker.thread_pool.size controls concurrent action execution and can bottleneck high-volume integrations if set too low
• IntegrationHub step execution writes to sys_log table with source com.snc.integration_hub, which can overwhelm log storage in verbose debugging scenarios
• Spoke installation automatically creates new sys_metadata records and can conflict with existing customizations if spoke names match custom-developed actions
• Session state and gs.getUser() context within IntegrationHub action scripts reflects the action's execution user, not the user who triggered the original flow or business rule

Debugging and Troubleshooting

When IntegrationHub actions fail, users typically see generic "Action execution failed" messages in Flow Designer, while admins need to dig into multiple log locations to find the root cause. The most common symptoms include actions appearing to succeed in Flow Designer but not actually affecting external systems, actions timing out without clear error messages, and credential authentication failures that manifest as "Connection refused" or "401 Unauthorized" errors. These failures often occur silently, with the only indication being failed records in the sys_hub_action_status table.

Start troubleshooting by navigating to System Logs > All and filtering by source com.snc.integration_hub to see detailed execution logs. Check IntegrationHub > Action Executions for specific action status and error details, particularly the Error and Output fields which contain the actual HTTP response codes and API error messages from external systems. Look for specific error patterns like "ConnectTimeoutException" (network issues), "SSLHandshakeException" (certificate problems), or "400 Bad Request" (malformed API calls).

The most critical debugging tool is enabling verbose logging by setting system property com.snc.integration_hub.log.level to debug, which exposes the full HTTP request/response cycle including headers and authentication details. When credential issues are suspected, check System Diagnostics > Credentials and run test connections to verify authentication before troubleshooting the action itself. Remember to disable debug logging after troubleshooting to prevent log table bloat.

Diagnostic Checklist:

• Check sys_hub_action_status table for the specific action execution record and examine the error field for detailed error messages
• Verify the credential configuration in Connections & Credentials > Credentials and test the connection independently
• Enable IntegrationHub debug logging and reproduce the issue to capture full HTTP transaction details
• Check external system API documentation for authentication requirements, rate limits, and required headers that may not be configured in the Spoke
• Verify network connectivity from ServiceNow to the external system using System Diagnostics > Network Utilities
• Review Flow Designer execution context to ensure input data is properly formatted and all required fields are populated
• Check if spoke version is compatible with target system's current API version, as API deprecations can break existing integrations

Quick Reference

• Action execution records in sys_hub_action_status are retained for 30 days by default, controlled by com.snc.integration_hub.action_status.retention_days property
• Maximum concurrent IntegrationHub workers defaults to 10 but can be increased via com.snc.integration_hub.worker.thread_pool.size for high-volume environments
• IntegrationHub actions timeout after 300 seconds (5 minutes) by default, configurable per-spoke but not per-action
• Credential records support field-level encryption but passwords are visible in plain text to users with credentials_admin role
• Spoke installations from the ServiceNow Store automatically update to latest versions unless specifically pinned to a version in System Applications > All Available Applications
• Flow Designer shows IntegrationHub actions as "successful" even when the external API returns 4xx or 5xx HTTP status codes, check sys_hub_action_status for actual results
• Custom IntegrationHub actions require the IntegrationHub Professional license, while using pre-built Spokes only requires base IntegrationHub licensing
• OAuth 2.0 credentials automatically refresh tokens but Basic Auth credentials never expire, creating potential security risks if not rotated manually
• IntegrationHub step debugging data includes full request/response payloads, which may contain sensitive data that persists in sys_hub_step_status table
• Asynchronous action calls from business rules execute under the system user context, not the original user who triggered the rule, affecting audit trails and ACL evaluation