4 essential steps when building an RPA bot

Image for post
Image for post
Photo by Alex Knight on Unsplash

Four main steps in a typical RPA project:

Extract — Clean — Update — Result.

Extracting the data

In an RPA project, data sources are usually text or Excel files attached in emails or located in shared folders within an organization. When the bot is retrieving the files, it will need to save the data source in a local machine or environment before extracting data into variables that are readable and changeable by the bot itself.

Data cleaning/validation

Like any data analytic projects, cleaning data is also an essential step in an RPA project. For the bot to execute a task smoothly, the data used by the bot must be clean and ‘acceptable’ by the system or application. If the bot did not pre-process the data source thoroughly, the bot would throw an exception rather than process the transaction as configured. If the bot has not been ‘taught’ to handle a particular scenario or exception, then most likely the bot will get stuck at a specific screen or in the middle of the executed tasks.

Data update/entry

When data has been cleaned and ready to be used by the bot, it is time for the bot to do the magic.

  • Automating data entry in an emulator or legend system: Scrapping the screen and building flexible keystroke shortcuts are essential to moving the cursor around in all kind of scenarios.

One rule of thumb when configuring the bot to do data update/entry: spy — scrap — enter.

Regardless of the system type that the bot will be automating on, the bot must be able to spy on the screen to see the elements. If the bot is not able to ‘see’ the screen, it will not be able to scrap the screen data to do data massaging. For example, if the bot is not able to locate the name field in SalesForce, then it would be impossible for the bot to enter any names retrieved from the Excel file into the system.

Process results

A typical RPA task usually ends by the bot providing the user reports.

There are three types of reports that a bot can provide — a transaction report, an audit report, and a statistics report.

A transaction report is usually printed by the bot back in the data source file or any other file types as long as it is easy for users to refer the printed results back to the original transactions. The bot will print results right after it finishes processing one transaction and before going to the next. A transaction report typically includes task status and remarks for failed executions. Using the name example again, if the bot failed to input Mark’s name because Mark provided more than 200 characters for his name, the bot will reject Mark’s input as it does not meet the system requirement and print the result in a designated Excel/text file as:

Image for post
Image for post
Photo by Franck V. on Unsplash

Conclusion

RPA bots work the best when the task to be automated is rule-based and requires minimal decision-making. By using RPA bots to do these redundant tasks, human are sparred from having a ‘robotic’ lifestyle and can spend more time on analytical tasks. Most importantly, RPA bots are available 24/7 to work, and… no complaints!

Written by

Changing the world with data points, one word at a time. #naturalLanguageProcessing #textMining #sentimentAnalysis

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store