From Blue Prism to PAD – A Practical Shift in Debug Log Automation

In payroll tax research at Vertex, Inc., debug logs are essential for verifying calculation results and troubleshooting during testing. For years, the Debug Log Loader process required a long series of manual steps—running SQL scripts, exporting data, formatting files, and publishing results for review. While effective, the process demanded significant analyst time and involved working with SQL, a powerful data analysis tool that not all team members are familiar with.

This solution bridges that gap, enabling analysts with little or no SQL experience to leverage the process efficiently and consistently.

To streamline this, I set out to automate the process to save time, reduce manual effort, and ensure consistency in how debug logs were uploaded and analyzed.

 

Preliminary Exploration: Blue Prism

The first solution we evaluated was Blue Prism, a leading enterprise-grade Robotic Process Automation (RPA) platform. Using standard automation fit criteria, the process was assessed as follows:

  • Repetitiveness: High (5)
  • Data Type: Structured (4)
  • Manual Effort: Moderate (3)
  • Rule-Based Logic: Low (2)
  • Technology Environment Complexity: High (1)

 

This produced an overall fit score of 3.00, indicating moderate suitability for automation.

However, the effort complexity was significant:

  • Multiple systems and tools were involved
  • Some process re-engineering was required
  • The flow had several variations despite structured data

Business Case Metrics

  • Estimated Annual Labor Hours: 5,717
  • Automation Coverage: 30%
  • P*Q Score: 1,715 — a metric that combines the potential impact of automation (P) with the process volume or effort (Q) to help prioritize which tasks are most valuable to automate

Despite the high potential for labor savings, implementing this through Blue Prism was not viable due to:

  • Integration challenges across analyst VMs and Oracle environments
  • The need for IT-managed infrastructure and governance
  • Low rule-based logic, making it difficult to build a stable, maintainable bot

 

Why Power Automate Desktop (PAD) Was Chosen

Recognizing these limitations, I built a solution using Power Automate Desktop (PAD)—a practical, low-code alternative that could be developed and maintained directly by analysts without requiring deep programming expertise.

PAD offered several advantages:

  • Seamless integration with local tools and file systems
  • No dependency on IT-managed RPA infrastructure

Because PAD is part of Microsoft’s Power Platform, it provides a low-to-no-code environment that empowers business users and analysts to automate repetitive tasks on their own—bridging the gap between technical and non-technical roles. For more on why SQLcl is particularly effective for automation, see my LinkedIn article on using SQLcl with PAD.

 

The Result

The new PAD flow now automates:

  • SQL script generation and execution
  • Exporting and formatting debug log results
  • File cleanup and publishing to SharePoint

It achieves the same goals originally envisioned for Blue Prism—eliminating 14 manual steps and enabling consistent, repeatable execution—but with a fraction of the setup effort and significantly faster deployment.

This shift from Blue Prism to PAD demonstrates a right-sized approach to automation: using accessible tools to solve real business problems, reduce manual work, and make process innovation achievable for analysts—not just developers.

To view or add a comment, sign in

More articles by Dorothy Chaloult, CPP

Others also viewed

Explore content categories