24 October 2017

Automation Anywhere – tips from an experienced implementer

Adrian Woffenden - one of Extra Technology’s senior RPA consultants - details some Automation Anywhere Dos, Don’ts and Bewares, based on real-life experience on customer deployments.

RPA is an emerging technology and Automation Anywhere is a market-leading vendor with products that continue to improve... so we all need help with tips and tricks.

I lead one of Extra Technology's RPA teams, working with global customers and gaining new Automation Anywhere experience on a daily basis. I am always happy to share my experiences and to look forward to hearing your feedback.

Here are some dos, don'ts and bewares that I would like to share to start the ball rolling (this advice may change as the product changes, my experience grows, and subject to the tips of my fellow members of the Automation Anywhere Forum:)

1. DON’T:

Don’t use Wait Loops for Object Cloning – it is a total waste of time, I see it time and time again (and they still do it at many Automation Anywhere customer sites!), a single object cloning timeout set to a high enough value is as effective as having a loop of short timeouts and is less misleading.

Don’t use Higher Screen Resolution for Screen Recording than is used for Playback - MetaBot screen recording at higher screen resolutions than the production system used for playback will give unpredictable results.

Don’t use differing variables between tasks – specifically this relates to calling a task from another task and mapping a variable or variables, the “Quick Map” feature will not work if the variables do not match exactly.

Don’t use Excel where CSV or XML will do – especially true for config files; reading a CSV or XML file requires fewer resources and does not need to open an application.

Don’t use Non-Robust Excel Macros – Non-robust Excel Macros have insufficient error handling within the macro code and may fail with an Excel debug message. At this time Automation Anywhere has no way to capture the error output and get past the debug message, thus leaving the automation in limbo.

2. DO:

Do use the “Wait for Window” command – but please keep in mind that it will only wait for the window title to exist, not for the window to load, so always follow it up with an object cloning or similar method which waits to find an element on the page which proves it has loaded. This is relevant to many applications, not just web sites.

Do use short-cut keystrokes – this is much preferred and much more reliable than searching for a button to click on. Beware though, some applications do not use standard shortcut keystrokes and some even change dynamically depending on content (e.g. Microsoft Dynamics). Always test in every scenario possible.

Do use Copy & Paste - Copy and paste lines and even entire sections between task scripts (it does work flawlessly, although I have heard rumours to the contrary).

Do consider using a local database - using a local MS Access database for storing information regarding the status of a process and other info – this is much faster than more convenient than using Excel files, despite the inconvenience of setting up the table format initially.

Do Export from tables to CSV files – very fast and easy to access afterwards.

Do use Error Handling extensively – This is a huge subject all on its own and detailed education is highly recommended (Extra Technology runs various AA education courses if you are interested www.extratechnology.com/training/automation-anywhere-courses - Remote training is an option. More courses are planned). Wherever you can get training, it is essential to understand how to make your RPA delivery robust - a failing robot is a very poor advertisement for RPA and should not be tolerated.


Mapping variables between tasks – Running a task (e.g. sub task) from another task (e.g. main task) and mapping the variables means the variables are always bi-directional, it is not possible to select a one-way direction and so not possible to avoid a modified variable coming back to the calling task (main task) from the called task (sub task). This is where “Quick Map” can catch you out, despite it’s apparent ease of convenience.

The system variable “AATaskName” does NOT return the task name alone! - AATaskName returns the complete path to the task which then needs further processing to cut it down to just the task name. It would be so much more convenient if there were a system variable which returned only the current task name in short form.

Avoid the system variable “Date” where possible – instead use “Day” “Month” “Year” etc. – This is because the returned format is inconsistent depending on the environment settings.

Consider sub-task failure detection/feedback - Called tasks (sub tasks) do NOT pass back their failure state to the calling task (main task) so it is impossible to detect a failure without adding Error Handling in the called task and somehow feeding it back to the calling task via a mapped variable.


Working with Automation Anywhere is a refreshing challenge, with the technology constantly improving and our working practices continuing to improve. The above tips apply to Automation Anywhere version 10.x. I am very interested to hear the views of other Automation Anywhere developers – in our niche there is always something to learn.

Adrian Paul Woffenden

Adrian leads a team of RPA consultants and provides help and advice across a number of projects in diverse sectors, including Banking, Energy and Pharmaceutical.

Copyright © Extra Technology Ltd. All Rights Reserved. All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.

Our Latest Blog Posts