RPA Hub

What It Is

RPA Hub is ServiceNow's integrated robotic process automation platform that deploys software robots to interact with legacy applications, web interfaces, and desktop systems that lack modern APIs. Unlike traditional integration approaches that require system-to-system connections, RPA Hub creates attended and unattended bots that mimic human interactions—clicking buttons, filling forms, reading screens, and navigating applications exactly as a user would. The platform solves the critical gap between ServiceNow's modern workflow capabilities and the reality that most enterprises still run on decades-old systems that were never designed for programmatic integration. RPA Hub transforms these manual, repetitive tasks into automated processes that can be triggered from ServiceNow workflows, reducing human error and freeing up resources for higher-value work.

Architecturally, RPA Hub lives within the Automation Engine application family, specifically under Process Automation > RPA in the application navigator. The platform consists of three core components: the RPA Hub management interface running on your ServiceNow instance, RPA Designer (the desktop robot-building tool), and RPA Runner (the execution engine that can run on Windows, Linux, or cloud environments). The data model centers around rpa_robot records that define automation scripts, rpa_execution records that track individual runs, and rpa_credential records that securely store authentication details for target systems.

The execution environment operates as a hybrid architecture where robot definitions are stored and managed centrally in ServiceNow, but actual automation runs on dedicated RPA Runner nodes that can access the target applications. These runners communicate back to ServiceNow through REST APIs and web sockets, updating execution status, logging activities, and returning data captured during automation runs. RPA robots can be triggered manually, scheduled through ServiceNow's standard scheduling engine, or invoked programmatically from Flow Designer actions, Business Rules, or Script Includes using the sn_rpa API family. This integration allows RPA to function as a natural extension of ServiceNow workflows, where a process might update a ServiceNow record, trigger an RPA robot to perform actions in an external system, and then continue the workflow based on the robot's results.

You cannot function without RPA Hub in enterprises where critical business processes depend on legacy mainframe applications, thick client desktop software, or web applications that lack APIs and cannot be modernized due to cost, complexity, or vendor limitations. The most common scenarios include automated data entry into ERP systems during employee onboarding, automated report generation from legacy financial systems for compliance reporting, automated customer data synchronization between ServiceNow and insurance policy management systems that only offer web interfaces, and automated invoice processing workflows that must interact with multiple vendor portals. RPA Hub becomes essential when manual processes create bottlenecks that prevent ServiceNow workflows from being fully automated, or when regulatory requirements mandate that certain actions be performed in specific legacy systems while maintaining audit trails in ServiceNow.

Platform owners typically handle RPA Hub infrastructure setup, runner deployment, and credential management, while ServiceNow administrators configure robot integrations with workflows and manage execution monitoring. Developers or business analysts with technical skills usually build the actual robots using RPA Designer's drag-and-drop interface, though complex scenarios requiring JavaScript scripting or advanced error handling often require developer involvement. The security model follows ServiceNow's standard patterns—robot definitions inherit the security context of the user account that triggers them, and RPA Hub respects table ACLs and role-based access controls when reading or writing ServiceNow data. This means your existing ServiceNow security architecture extends naturally to RPA operations without requiring separate permission systems.

Recent Vancouver and Washington releases introduced significant improvements to RPA Hub's integration capabilities, including native Flow Designer actions that eliminate the need for custom scripting when triggering robots from workflows. The Vancouver release added enhanced credential management with support for multi-factor authentication scenarios and improved error handling with automatic retry logic for common failure patterns. Washington expanded robot monitoring with real-time execution dashboards and introduced RPA Robot as a Service capabilities for cloud-based runner deployment. These changes reduced the technical complexity of RPA implementations and improved reliability for production environments, making RPA Hub more accessible to administrators who previously needed developer support for complex integrations.

Where to Find and Configure It

Navigate to Process Automation > RPA > RPA Hub for the main management interface where you configure robots, manage executions, set up credentials, and monitor performance metrics. Use Process Automation > RPA > Robots to access the robot catalog, upload new robot definitions, and configure execution parameters. Access Process Automation > RPA > Executions to view execution history, debug failed runs, and analyze performance trends.

For integration configuration, go to Process Automation > Flow Designer to add RPA actions to your workflows using the RPA - Execute Robot spoke action. Configure credentials securely at Process Automation > RPA > Credentials where you store usernames, passwords, and authentication details that robots need to access target systems. Set up RPA Runner connections through Process Automation > RPA > Runners to register execution nodes and configure their capabilities.

View RPA activity in action through the rpa_execution table which shows real-time execution status, start/end times, and output data. Monitor system health via rpa_runner records that track runner availability and resource utilization. Check the rpa_robot table for robot definitions, version history, and execution statistics. RPA Hub operates identically in scoped and global applications, though scoped applications can only access robots and credentials within their application scope unless explicitly granted cross-scope access through application access controls.

How It Works Step by Step

RPA Hub operates through a distributed execution model where ServiceNow acts as the central control plane while RPA Runners perform the actual automation work. When a robot execution is triggered—whether manually, through a schedule, or programmatically via Flow Designer—ServiceNow creates an rpa_execution record and queues the job for dispatch to an available runner. The system evaluates runner capabilities, current load, and robot requirements to select the optimal execution node. ServiceNow packages the robot definition, input parameters, and credential references into a secure execution payload that gets transmitted to the selected runner via encrypted web socket or REST API calls.

The RPA Runner receives the execution request, validates the robot definition, retrieves necessary credentials from ServiceNow's credential store, and begins executing the automation script. During execution, the runner continuously sends status updates, log messages, and captured data back to ServiceNow, which updates the rpa_execution record in real-time. If the robot encounters errors, the runner implements retry logic based on the robot's configuration, attempting recovery actions or failing gracefully with detailed error information. Upon completion, the runner packages all output data, screenshots, and execution artifacts, transmitting them back to ServiceNow where they're stored and made available to downstream workflow steps or human reviewers.

The Execution Order

1. ServiceNow evaluates the trigger condition and creates an rpa_execution record with status Queued
2. The RPA dispatcher selects an available runner based on capabilities and load balancing rules
3. ServiceNow packages robot definition, input parameters, and credential references into execution payload
4. Execution payload is transmitted to the selected runner via secure channel, status changes to Running
5. RPA Runner validates robot definition and retrieves credentials from ServiceNow credential store
6. Runner executes robot steps sequentially, sending progress updates back to ServiceNow
7. Each robot action (clicks, data entry, screen capture) is logged and transmitted to ServiceNow
8. Upon completion or failure, runner packages output data and execution artifacts
9. Final results are transmitted to ServiceNow, updating execution status to Completed or Failed
10. ServiceNow triggers any configured post-execution workflows or notifications based on results

// Business Rule to trigger RPA robot when incident priority changes to Critical
(function executeRule(current, previous) {
    if (current.priority == '1' && previous.priority != '1') {
        var rpaAPI = new sn_rpa.RobotExecutionAPI();
        
        var robotSysId = 'a1b2c3d4e5f6789012345678901234'; // Robot sys_id
        var inputParams = {
            incident_number: current.number.toString(),
            caller_email: current.caller_id.email.toString(),
            short_description: current.short_description.toString()
        };
        
        var executionSysId = rpaAPI.executeRobot(robotSysId, inputParams);
        
        current.work_notes = 'RPA robot triggered for critical incident notification. Execution: ' + executionSysId;
        current.setWorkflow(false);
        current.update();
    }
})(current, previous);

Real-World Scenarios

Automated Employee Termination in Legacy Payroll System

When HR initiates employee termination through ServiceNow, the legacy mainframe payroll system must be updated to stop salary payments, but the system only provides a green-screen terminal interface with no API access. The RPA robot must log into the terminal, navigate through multiple screens, enter the employee ID, update termination status, and capture confirmation screenshots for audit compliance.

Create a new robot in RPA Designer that connects to the terminal emulator, uses stored credentials from Process Automation > RPA > Credentials for secure login, and implements screen recognition to navigate the mainframe interface. Configure the robot to accept input parameters including employee ID, termination date, and reason code from the ServiceNow termination workflow. Set up a Flow Designer subflow that triggers when the HR case state changes to Approved, extracts employee data from the HR record, and calls the RPA - Execute Robot action with the required parameters. Configure error handling to retry failed screen interactions and escalate to HR if the robot cannot locate the employee record after three attempts.

Watch for terminal session timeouts that can cause robot failures—implement keep-alive actions in the robot script and configure session refresh logic. Mainframe screen layouts change during system maintenance windows, so build robot scripts with flexible element recognition rather than fixed screen coordinates. Set up proper credential rotation schedules since the robot account needs mainframe access but should follow the same password policies as human users.

Automated Invoice Processing with Vendor Portal Data Entry

Your procurement workflow needs to automatically submit approved purchase orders to vendor web portals that require manual form completion through their websites. Each vendor has different portal layouts, authentication requirements, and field validation rules that prevent standard API integration approaches from working effectively.

Build separate robots for each major vendor portal using RPA Designer's web automation capabilities, configuring each robot to handle specific vendor authentication flows and form structures. Store vendor credentials securely in the RPA credential vault and configure each robot to accept standard purchase order data (PO number, line items, quantities, delivery dates) as input parameters. Create a master Flow Designer workflow that reads approved purchase orders from the proc_po table, determines the appropriate vendor robot based on the supplier field, and triggers the correct RPA robot with normalized data. Configure each robot to capture confirmation numbers and upload them back to ServiceNow by updating the purchase order record's vendor_confirmation field and attaching portal screenshots as evidence records.

Vendor portals frequently update their web interfaces without notice, breaking robots that rely on specific CSS selectors or element IDs—implement robust element detection using multiple identification methods including text content and relative positioning. Handle vendor portal maintenance windows gracefully by configuring retry logic with exponential backoff and escalation to procurement staff when portals are unavailable for extended periods. Monitor robot success rates closely since vendor portals often implement anti-automation measures that may require robot behavior adjustments to appear more human-like.

Automated Customer Data Synchronization with Insurance Policy System

Customer service representatives update customer information in ServiceNow, but the legacy insurance policy management system requires manual data entry to keep customer records synchronized. The insurance system lacks APIs and runs as a thick client application that agents must access through Citrix virtual desktops.

Deploy RPA Runner on the Citrix infrastructure with access to the insurance application, then build a robot that can launch the application, authenticate using service account credentials, and navigate the customer update screens. Configure the robot to receive customer data from ServiceNow including policy numbers, updated contact information, beneficiary changes, and address modifications through standardized input parameters. Set up a Business Rule on the customer table that triggers when specific fields are updated and the sync_to_insurance checkbox is marked true, automatically queuing the robot execution with the changed customer data. Program the robot to validate data entry by comparing screen values with the input parameters and capturing success confirmations or error messages for audit trails.

Citrix environments introduce latency and screen rendering delays that can cause robot timing issues—implement generous wait times and screen state validation before proceeding with each action. The insurance application may lock customer records during updates, so configure the robot to detect lock messages and implement exponential backoff retry logic with maximum attempt limits. Consider network disconnections in the Citrix environment by programming the robot to recognize connection loss scenarios and restart the application session when necessary, maintaining execution state through persistent variables stored in ServiceNow.

The Classic Mistake

Teams frequently build RPA bots to log into ServiceNow through the web interface, navigate to forms, and fill out fields using screen scraping. They create workflows that use Element Click activities to click New buttons, Type Text activities to populate Short Description and Assignment Group fields, then click Submit. This approach treats ServiceNow like a legacy application without APIs when ServiceNow is specifically designed for API integration.

This fails because UI-based automation is brittle and slow compared to API calls. Users see intermittent failures when ServiceNow UI updates change element selectors, and performance degrades significantly since the bot must wait for page loads and DOM rendering. ServiceNow internally processes each UI interaction through the full web stack including session management, form rendering, and client-side scripts, creating unnecessary overhead. The mistake is non-obvious because the UI approach initially works, making teams think they've solved the integration problem when they've actually created a maintenance nightmare.

// RPA workflow using ServiceNow REST API
var endpoint = 'https://instance.service-now.com/api/now/table/incident';
var headers = {
    'Authorization': 'Basic ' + base64Encode(username + ':' + password),
    'Content-Type': 'application/json',
    'Accept': 'application/json'
};

var payload = {
    'short_description': extractedData.description,
    'assignment_group': 'Hardware',
    'caller_id': extractedData.userId,
    'category': 'Hardware',
    'subcategory': 'Computer'
};

var response = httpPost(endpoint, headers, JSON.stringify(payload));
var incidentNumber = JSON.parse(response.body).result.number;

When to Use This vs Alternatives

RPA Hub is the right choice when you need to automate interactions with legacy desktop applications, mainframe terminals, or web systems that lack APIs and resist integration attempts. The core use case is bridging the gap between ServiceNow workflows and systems that only accept human interaction through their original interfaces.

Choose RPA Hub When

Use RPA Hub for thick client applications like SAP GUI, AS/400 terminals, or proprietary desktop software where REST APIs and Integration Hub ETL operations cannot reach. RPA excels when you need to extract data from PDF documents, navigate complex multi-step processes in legacy web applications, or automate tasks that require visual recognition of UI elements. Traditional integration approaches fail here because these systems were designed for human operators, not programmatic access.

Use Integration Hub Instead

Choose Integration Hub when the target system has REST APIs, SOAP web services, or database connectivity available. Integration Hub handles authentication, error handling, and data transformation more reliably than RPA for API-enabled systems. File-based integrations using SFTP, email parsing, or scheduled imports should also use Integration Hub rather than RPA automation that mimics manual file handling.

Hybrid Approach Scenarios

Combine RPA Hub with Integration Hub when you need to gather data from legacy systems via RPA and then push that data to modern systems via APIs. Use Flow Designer to orchestrate the sequence: RPA extracts data, Flow Designer processes and validates it, then Integration Hub delivers it to the final destination. This pattern works well for modernization projects where legacy system replacement is planned but not yet complete.

Platform Interactions & Side Effects

• RPA workflow executions create records in sys_rpa_execution table with detailed step-by-step logs and execution status
• Flow Designer subflow triggers consume process automation licenses separately from RPA Hub bot execution licenses
• Business Rules on tables modified by RPA workflows execute normally but cannot detect that changes came from automation rather than users
• RPA credentials stored in discovery_credentials table use ServiceNow's standard encryption but require rpa_admin role for access
• Update Sets capture RPA workflow definitions but not runtime configurations or desktop agent settings
• MID Server relationships break if RPA desktop agents lose connection, causing workflow executions to fail silently without proper error handling
• Performance Analytics widgets cannot directly query RPA execution data without custom scripts due to table relationship limitations
• Notifications triggered by RPA-modified records use the RPA service account as the sender, potentially confusing recipients about the source
• RPA workflows bypass client scripts and UI policies completely, potentially creating data inconsistencies if validation logic exists only on the client side
• Desktop agent memory usage accumulates during long-running workflows, requiring periodic restarts on Windows servers to prevent resource exhaustion

Debugging and Troubleshooting

The most common failure symptoms include workflows that start but never complete, with the execution status stuck in Running state indefinitely. Users see triggered workflows that appear to execute successfully but produce no results in target systems. Administrators notice intermittent failures where the same workflow succeeds manually but fails when automated, often accompanied by Element not found or Timeout waiting for response error messages in execution logs.

Start troubleshooting in Process Automation > RPA > Executions to view detailed step-by-step logs showing exactly where workflows fail. Check System Logs > System Log > All for MID Server connectivity issues that prevent desktop agent communication. The RPA Desktop Design Studio includes a debug mode that highlights UI elements and shows real-time execution status during workflow testing.

Look for specific error patterns: Could not establish connection to desktop agent indicates network or MID Server problems, while Activity execution timed out after 30000ms suggests target applications are responding slowly. Screenshot captures in failed executions often reveal popup dialogs or unexpected screen states that block automation progress. Enable com.glide.rpa.debug system property for verbose logging of all RPA communications.

Diagnostic Checklist:

• Verify MID Server status in MID Server > Servers shows Up status and recent heartbeat
• Test desktop agent connectivity using Test Connection button in RPA agent configuration
• Check Windows Event Viewer on desktop agent machines for RPA service startup errors or permission issues
• Validate target application versions and patch levels match workflow recordings
• Review credential expiration dates and test authentication independently
• Monitor desktop agent CPU and memory usage during workflow execution for resource constraints
• Run workflows manually through Design Studio to isolate automation logic from scheduling issues

Quick Reference

• RPA workflows have a maximum execution time of 60 minutes before automatic termination, configurable via com.glide.rpa.execution.timeout property
• Desktop agents require Windows Server 2012 R2 or newer and cannot run on domain controllers due to service isolation requirements
• Concurrent workflow execution limit is 10 per desktop agent, with additional executions queuing until slots become available
• Screen resolution changes on desktop agent machines break UI element recognition and require workflow re-recording
• RPA execution logs retain for 30 days by default, controlled by cleanup_rpa_executions scheduled job
• Variable names in RPA workflows are case-sensitive and cannot contain spaces or special characters except underscores
• Excel automation requires Microsoft Office installation on desktop agent machines; Office 365 web versions are not supported
• Citrix and RDP environments require special configuration and may experience timing issues due to display compression
• Security policies blocking unsigned executables prevent RPA agent installation without specific Windows Defender exclusions
• RPA workflows triggered from Flow Designer inherit the security context of the Flow trigger, not the RPA service account