The RPA Recorder Myth

The RPA Recorder Myth

July 20, 2020

Today, with an increased demand for #RPA solutions spanning organizations across all vertical markets, the Automation CoE (Center of Excellence) is often faced with a heavy automation pipeline yet insufficient resources to respond quickly. One of the CoE’s goals is to increase TTM (Time To Market). This exacerbates the pressure to accelerate the implementation process and shorten the time from development to production.

One of the popular methods to achieve this goal is to leverage the recorder function that is embedded in RPA tools. These recorders are used in an attempt to speed up the development process by capturing the process actions,  and creating an automation workflow from the actions.

In a technical nutshell, the RPA process recorder aims to shadow the steps that a user performs and translates those into an automation-ready visual routine or workflow. Recorders typically embed a replication of the actions performed by a user, inside the workflow. For example, if the user initiates copying a file by left clicking on the file in Windows Explorer, the recorder will capture the specific coordinates of the file and emulate the associated action – in this case, a left click of the mouse.

It should be noted that some recorders are more sophisticated than others; smarter ones will capture elements using object-based connectivity, instead of capturing screen coordinates.

I would like to debate just how useful this recorder functionally is in reality - how robust is it, and which processes can it be used in?

From my initial description of how the recorder works, the tool only allows for a linear automation to be recorded i.e. a sequenced automation with one path through specific actions, with no possibility to deviate. Decision points are not possible in a recorded workflow tree, because the recorder is a simplistic tool that cannot recognize and evaluate decisions embedded within the process (see below graphics).

[caption id="attachment_14724" align="alignnone" width="361"]

[caption id="attachment_14725" align="alignnone" width="380"]

Nonlinear automation[/caption]

Although RPA software is a powerful tool, it is essential that all automations used within an organization must  meet a minimum standard of quality, usability and maintainability. As such, many RPA practitioners today wish there was a magic formula or magic tool to develop automations quickly while maintaining these standards.

Unfortunately, on its own, the recorder is not that magic tool. The recorder approach too easily allows for sub optimal design; it creates a solution with no separation between the logic layer, physical layer and data layer, making it an unreliable solution to reuse.  The reality is that automations which are built this way are very difficult to maintain. Using the recorder causes duplicate elements and workflows when recording different flows over the same screens, and minor changes in underlying screens or processes will cause disproportionate re-writes of the automation.

Experienced automation professionals will agree that a very high percentage of processes contain decisions points that need to be implemented as well as multiple exit points and exceptions to be handled. A linear automation simply cannot support this level of complexity.

Assuming you are building a robust workflow, you will need to deliver a production-grade solution, and the screen captures and transitions from step to step, made by a recorder, will need to be changed and customized, such as enhancing the screen connectivity properties or listening for a certain event in the exit transition from the automated step.

I would like to clarify that most processes require designed-based automation. This approach may involve more planning with appropriate solution architecture design resources and more cross-team collaboration. It is, however, the correct approach for building complex production-grade automation solutions which comply with standards of modularity, usability, scalability, maintainability, robustness, etc.

Once you have a detailed solution design, you can then consider building small sequences using the recorder functionality (taking into account the above points). Hence recorders can be effectively used as a starting point for simple, short sequences within a well-designed automation solution.