You have started your automation journey with the Automation 360 platform and now you have to define a framework for all the developers to follow and use the best practices guide to ensure everyone follows the same standards. Before we dive into what the guardrails that need to be set up are, let’s try to understand why we even need these best practices for your automation initiative.

• You have hired a new set of engineers and they have joined from various organizations in which everyone had followed different standards and methodologies to develop the bots. It becomes important for them to know the standards followed here so they can all build in a similar fashion.
• If any of your existing engineers move on from the organization, the person replacing this engineer should be able to read and understand the standard with which the bots were developed earlier and continue to update with the same standards.
• Even if you have to allocate your engineers across different projects or even different departments, the learning curve to understand the existing automations reduces significantly.

Now that you understand why it's important to have these standards, let's dive into what some of the best practices are that need to be followed.

Building reusable components - Single Responsibility Principle

Developing for reusability is all about how processes can be broken down into components that may find use/reuse across multiple automation opportunities. If automations are developed using the Single Responsibility Principle, the result will be many smaller Bots, many being reusable. These smaller Bots can then be tested alone, in a unit-test fashion.

Bot Naming

Use PascalCasing for Bot names. Pascal Case is the practice of writing compound words or phrases such that each word or abbreviation begins with a capital letter (e.g., PrintUtility). Always keep Bot names short and concise and consider limiting use of unnecessary characters such as underscores and blank spaces in Bot names.

Variables Naming

Use camelCasing for Variables. Camel Case is the same as Pascal Case, except that it always begins with a lowercase letter (e.g., backgroundColor). Avoid single-character variable names as it is very hard to understand the context for such variable names. A reader should always be able to look at a variable name and gain some clue about what it is for, e.g., pStrEmployeeFirstName or pNumSocialSecurityNumber.

Usage of Sessions

A “session” can be thought of as a reference point to external files/data and is a part of Actions such as Excel Basic/Advanced: Open, XML: Start session, etc. Once a Session Name is defined in such an Action, then the same file/data set can be accessed within subsequent actions, for example, Get Cells, just by specifying the same session name. Therefore, having a unique and meaningful Session name is essential. Avoid using “Default” as the session name, as it becomes vague to understand what this session is referring to. You may also use a variable in place of a session name, which will further reduce the possibility of making typos while typing Session names in actions. Make sure you close all the sessions that you open, to release lock/hold on external data sources.

Usage of Steps

The “Step” action is a powerful way to organize actions into logical groups. When used effectively, use of the action improves the readability of the code. Use the Step action liberally in code, grouping related actions. Always include a title for the action and try to limit it to no more than a few words. Make titles meaningful and avoid non-descriptive titles like “Step 1”.

Commenting

Most automations require changes after they are placed into production. Sometimes those changes can be frequent, depending on the type and scope of the automation. The difference between a change being a straightforward Bot and a complete nightmare is determined by two things: how cleanly the automation was architected, and how well it is documented and commented. Good commenting can mean a difference in hours during a maintenance cycle. Use comments to explain logic insights, assumptions, and/or known issues.

Setting up Global Values

For values that are applicable across Use Cases, implement them using the Global Values functionality. Some examples may include Delay Times, Application URLs / Server Names, Root Folder Path on Bot Runner for files related to Bots, etc., Since “Global Values” are managed as part of a Control Room, they are by nature “environment specific”. As a Bot is promoted through different environments, the Bots can access different values for these parameters, as necessary.

Takeaways and Conclusion:

Setting up these guardrails to ensure your automation initiative does not turn out to become a shadow IT is critical for any project's success. It’s important that the CoE not only establishes good practices for development but also model these practices for every business unit to follow. With well-defined development standards, business units and the CoE can focus on delivery as opposed to re-creating the wheel every time a new bot is created.

• Clearly defined development standards enable easier supportability of bots

• Though it may take time to follow these best practices, it will save a lot of time and ensure smooth functioning eventually

• Refer to the Automation Anywhere recommended best practices guide to be followed while developing the bots