As the sole robot master of my IT team, I’ve spent a considerable amount of time automating some of our back-office applications at my place of work. One of the biggest lessons I learned—when I descended into the real world with my hard-earned Robotic Process Automation (RPA) knowledge around my belt—was the sensitivity with which humans would treat a process when it was taken away from their hands and put into the charge of a software robot.
The more sensitive and confidential the nature of the function performed by the back-office process/application, the more scrutiny the robot attracted.
One such area, which (ironically) is most ubiquitous and often taken for granted, is application and error logging. As an RPA application builder, I relied on application logging to develop and test our RPA processes. Also, these logs were immensely helpful in demonstrating the workings of a robot to “robot owners” who would finally own and operate their robots once it was deployed (after due process). This is when I realized that in my line of work, managing application logs in our RPA application was quickly going from becoming an asset, to a necessary inconvenience.
- • Be in a state of readiness to better manage the logs of the Robots output as they went about their daily business
- • Place the configuration setting in an external file and enable your RPA process to read this setting on startup.
• Alter the signature of your startup Main.xaml file (as shown below) to accept an input argument that can then be overridden at the Process level or Job level when you finally deploy to the Orchestrator.