I wanted to share our successful implementation of automated case routing for HR onboarding that reduced manual routing time by 75% and virtually eliminated SLA breaches. Our HR team was struggling with manually routing 200+ onboarding cases per month to the correct department specialists based on employee type, location, and role complexity.
We implemented a solution combining RPA integration with dynamic decision tables that allows business users to maintain routing rules without IT involvement. The system now automatically routes cases within 2 minutes of creation, compared to the previous 30-60 minute manual process. The RPA component handles data extraction from legacy HR systems, while Pega’s decision tables determine the optimal routing path based on multiple criteria including workload balancing across specialists. Would be happy to discuss the architecture and lessons learned from this project.
Yes, the workload balancing was a key requirement. We created a decision table with three tiers of routing logic. First tier checks employee type and location to identify eligible specialists. Second tier evaluates role complexity scores. Third tier queries current active case counts per specialist and routes to the one with lowest load. The decision table references a data page that refreshes every 5 minutes with current workload metrics from the assignment reports.
Excellent use case that demonstrates the power of combining multiple Pega capabilities. I’d like to add some architectural insights that might help others implementing similar solutions.
For the RPA integration component, the key success factor is designing a robust connector layer between the robotic automation and your case management flow. Create a dedicated integration service that handles the RPA invocation asynchronously, allowing the case to proceed even if data extraction takes longer than expected. Use queue processors to manage retry logic and implement circuit breaker patterns to prevent cascading failures when legacy systems are unavailable.
Regarding dynamic decision tables for routing, structure them hierarchically for maintainability. Your primary decision table should handle the high-level routing logic based on employee attributes, while secondary tables manage specialist availability and workload distribution. This separation allows business users to modify routing criteria without affecting the workload balancing algorithms. Implement version control and approval workflows for decision table changes to maintain governance - business users can propose changes, but a designated administrator approves them before production deployment.
For business-managed routing rules, provide HR users with a simplified interface using guided decision tables with pre-defined column templates. Limit the properties they can add as conditions to a curated list of HR-relevant attributes. Set up automated testing that validates decision table logic against historical case data before changes go live. We’ve found that 2-3 hours of initial training plus monthly office hours is sufficient for business users to confidently manage their routing rules.
One critical lesson learned: instrument your routing decisions with comprehensive logging. Capture which decision table rows fired, what conditions matched, and the resulting specialist assignment. This audit trail is invaluable for troubleshooting routing issues and helps business users understand how their rule changes affect case distribution. Create a simple dashboard showing routing patterns and SLA compliance metrics that business users can access to validate their changes.
The 75% reduction in manual routing time you achieved is impressive and aligns with typical results from well-implemented automated routing solutions. The real ROI comes from the SLA compliance improvement and the ability to scale the onboarding process without adding staff. Consider extending this pattern to other HR processes like offboarding, internal transfers, or benefits enrollment changes.
This sounds like exactly what we need for our onboarding process. Can you share more details about how you structured the decision tables? We’re particularly interested in the workload balancing aspect - does it check current case counts per specialist?
The business-managed routing aspect is really interesting. How much training did your HR team need to maintain the decision tables themselves? We’re trying to reduce our IT backlog by empowering business users, but there’s concern about rule quality and governance.
We used Pega Robotic Automation integrated through the RPA component in Pega 8.6. The bot connects to our legacy HRIS system, extracts employee master data, and populates the case. For error handling, we implemented a fallback mechanism - if RPA extraction fails after 2 retries, the case routes to a manual data entry queue with an SLA of 4 hours. This happens less than 3% of the time, usually due to system downtime. The RPA bot also performs data validation before passing to Pega, which catches formatting issues early.
How did you handle the RPA integration piece? We have similar legacy systems that don’t have APIs. Did you use Pega RPA or a third-party tool? Also curious about error handling when the RPA bot fails to extract data from the legacy system.