Automated case escalation for HR onboarding using RPA bot with REST API polling

BPM ServiceNow
, , , , , , , ,
1

I wanted to share our successful implementation of automated case escalation for HR onboarding cases that reduced manual escalation handling and improved SLA compliance significantly.

Background: Our HR onboarding process in ServiceNow Tokyo handles 200+ new hire cases monthly. Cases frequently stalled in ‘Pending Manager Approval’ state, causing SLA breaches. Manual escalation required HR coordinators to monitor dashboards and send reminder emails, consuming 10-15 hours weekly.

Solution - RPA Bot with API-Driven Escalation: We deployed an RPA bot that polls the case management API every 2 hours to identify stalled cases and automatically escalates them based on configurable rules:


GET /api/now/table/sn_customerservice_case
?sysparm_query=state=pending_approval^opened_at<javascript:gs.daysAgoStart(2)

The bot retrieves cases pending over 48 hours, checks SLA compliance status, and triggers escalation actions via REST API - updating case priority, assigning to manager’s supervisor, and sending automated notifications.

Results:

  • Manual escalation time reduced from 10-15 hours/week to zero
  • SLA compliance improved from 73% to 94%
  • Average approval time decreased from 5.2 days to 2.8 days
  • HR coordinator capacity freed for higher-value activities

The case polling automation runs continuously without human intervention, and the API-driven approach ensures all escalation actions are logged in ServiceNow audit trails. Happy to discuss implementation details for anyone considering similar automation.

2

What about error handling when the API calls fail? Network issues or ServiceNow maintenance windows could cause the bot to miss escalation windows. Do you have retry logic or alerting for bot failures?

3

We initially considered event-driven webhooks, but our RPA platform (Automation Anywhere) handles scheduled polling more reliably in our environment. The 2-hour interval was chosen based on SLA thresholds - cases don’t need escalation more frequently than that. API load is minimal since we filter by date and state, typically returning 5-15 cases per poll. Event-driven would be more elegant but added complexity we didn’t need for this volume.

4

Excellent question - this was a key design decision. We store escalation rules in a custom ServiceNow table (u_escalation_rules) with fields for:

  • Case state
  • Days pending threshold
  • Priority escalation level
  • Notification template
  • Escalation assignment group

The RPA bot queries this table at the start of each polling cycle, so HR admins can modify rules through ServiceNow without touching the bot. This gives business users control over escalation logic. The bot essentially becomes a rule execution engine rather than having hardcoded logic.

Implementation Summary:

Case Polling Automation: Our RPA bot runs on a 2-hour schedule, executing this workflow:

  1. Query escalation rules from custom table
  2. Poll case management API for cases matching rule criteria
  3. For each matching case, execute escalation actions
  4. Log all actions to custom escalation audit table
  5. Send summary report to HR operations dashboard

Key API calls:


// Fetch escalation rules
GET /api/now/table/u_escalation_rules?sysparm_query=active=true

// Query stalled cases
GET /api/now/table/sn_customerservice_case
?sysparm_query={dynamic_query_from_rules}

// Update case priority and assignment
PATCH /api/now/table/sn_customerservice_case/{sys_id}
{
  "priority": "2",
  "assigned_to": "{supervisor_sys_id}"
}

API-Driven Escalation: The bot performs these actions via REST API:

  • Updates case priority based on escalation level
  • Reassigns case to manager’s supervisor (queried from user hierarchy)
  • Adds case comment documenting escalation reason
  • Triggers email notification using ServiceNow notification templates
  • Updates custom SLA tracking fields

All actions use the same service account with appropriate roles (sn_customerservice_agent, itil, rest_api_explorer). This ensures proper audit trails and security.

SLA Compliance Improvement: The dramatic improvement from 73% to 94% SLA compliance came from several factors:

  • Consistent escalation timing (no human delay)
  • Supervisor visibility forcing faster approvals
  • Automated reminders eliminating forgotten cases
  • Data-driven escalation rules (not subjective judgment)

We track SLA metrics in Performance Analytics dashboards that compare pre-automation and post-automation periods. The 2.8-day average approval time (down from 5.2 days) directly correlates with reduced case aging in pending states.

Lessons Learned:

  1. Start with simple polling logic, add sophistication later
  2. Externalize business rules to ServiceNow tables for flexibility
  3. Implement comprehensive error handling and monitoring from day one
  4. Use ServiceNow’s audit capabilities rather than building separate logging
  5. Involve HR business users in rule configuration to ensure adoption

For organizations considering similar automation, I recommend starting with a pilot on one case type, measuring results for 30 days, then expanding scope. The ROI is compelling - our implementation cost was recovered in 3 months through eliminated manual effort alone, not counting the SLA compliance improvements.

5

I’m curious about the configurable rules you mentioned. How do you manage escalation rule changes without redeploying the RPA bot? Are the rules stored in ServiceNow or in the RPA platform?