This article is part of a broader series that forms the Automation Success Framework. Please click on the link to view all topics. Note that there is a considerable amount of interdependency between each of the topics. For example, your choice of model for the automation Centre of Excellence (CoE) will influence how you need to configure the Control Room, and will also influence the roles involved in the Automation Lifecycle.

The purpose of this particular article is to outline a suggested best practice configuration for the Automation 360 control room to support the below objectives. 

This post will walk you through the process of configuring the below model to meet the above objectives.

It should be noted that every organisation is different, and this configuration may not suit all scenarios. The approaches outlined in this document can be customised by the platform administrator as required. Note also that this document must not be considered a replacement for reading the online documentation or for training in administration of the Automation Anywhere platform. As a minimum, a platform administrator should review all items in the Settings menu and broadly understand their purpose. 

Functionality in the platform changes over time, so some screen shots and menu items shown in this document may not exactly match your system. The concepts discussed however remain the same and should be able to be applied to future versions.

Admin Users

When your Automation 360 control room (CR) is first setup it will have a single Admin user defined. An admin user is one who has the AAE_Admin system role assigned. This role provides access to all menu options under the Administration section, including the Settings option. The Settings menu allows configuration of settings that define how the CR works. For proper separation of duties, the Admin user cannot also be a bot developer or runner and should only be used for administration of the platform. If you are unable to login as your Admin user you will be unable to administer the platform. You should therefore immediately create another Admin user so you have a backup user available to administer the platform.

The Important Settings

The following are the important settings to think about from the outset. Getting these right will help you avoid reconfiguration later on and ensure smooth operation from the outset.   

User authentication

Consider how you would like your users to be authenticated when accessing the control room. The different options are outlined on our documentation site. Note that only one authentication method can be used. Changing this configuration will require a significant amount of re-work to create new users and reassign roles, so it helps to choose the preferred option carefully from the outset. If using database driven accounts then you should also configure the Security Settings.

External key vault

When using an external vault all credentials are stored in a 3rd party vault rather than encrypted in the Automation Anywhere credential vault. A key benefit of using 3rd party vaults can be tighter integration with the operating system, which allows for routine cycling of bot runner device passwords. 
 

Integration with code repository

Automation 360 maintains a complete version history of your automations. You can compare versions and restore any version. while integration with a code repository can be configured, the main driver is for a code backup. Typically the production control room is configured with integration, as you want backup of your live bots rather than incomplete Dev versions. Note that a control room in the SAAS cloud is already backed up, so integration may be considered unnecessary in such cases.

Email / Notification Settings

It is important to be notified ASAP when an automation fails. Notification logic can be added to the actual bot logic, but can also be set at the platform level in Settings. In the Email settings you can choose which events trigger an email. In the Notifications settings configure the email accounts or group to be advised when automations fail. This should include the automation Centre of Excellence (CoE) team.

Setup Folder Structures

Folder structures are used to both organise your bot logic and to control access to bots. It is therefore important to design a proper folder structure from the outset. A good folder structure will support sharing and re-use of bot logic and the ability for different business units to manage their own bot logic securely. Depending on organisational requirements,
it may make sense to have subfolders under the business unit folders. But note that custom security roles will need to be created for each folder that needs to be secured.
 

Reusable Logic

To support sharing and re-use a folder should be created under the root folder in Public for re-usable bot logic. This folder should be given a name that highlights its purpose, such as “Reusable Logic”. Sub-folders should be created under this folder to organise content. The following subfolders are suggested:

• Utilities: his folder will contain bots to be re-used for utilitarian purposes such as logging and error handling.
• Templates: This will contain bot templates for various use cases. Templates should contain organisational standards to guide bot creators. (Note that templates functionality is coming which may supersede this approach).
• Business application specific folders: Many re-usable components will be built around specific business applications, such as Salesforce, SAP, Workday etc. So that developers can easily find these components they should be stored under business application specific sub folders in the Reusable Logic folder.

Business Unit Folders

Each business unit will generally require their own secure area for storing automations. This means they will need their own sub-folder. Even if business units do not require bots to be secured, it is likely that organising bots into folders by business unit will still make sense. This is because bots are built to automate processes, and processes typically belong to a specific business unit.
 

Company Wide Logic

If your organisation uses attended bot runners, then it is likely there will be some automations that all users will need access to. A folder should be created for these with a name that highlights its purpose, (e.g. “Company wide logic”).
 

Folder Roles

By default, new users do not have access to any folders or bots in the Public section of the control room. Custom security roles must be created to grant them access to these folders. Broadly, there are two types of access required:

1. Bot runners (unattended and attended) will require limited access to run the bots. 
2. Bot creators will need greater access to folders so they can copy or clone bots from the public folders, and potentially to delete bots and check them into public folders.

Roles used to grant access to folders should generally be limited to that purpose. Do not combine roles that grant functional access with folder access, as this will become hard to manage. We will use the system roles to grant users access to functionality later on. 

Below we discuss the folders for which you will need to create roles. Note the following:

• If a centralised CoE model is used, the developer roles can cover all folders, and only consumer roles are needed for each business unit.
• In a federated model, developers exist in business units, so you will need separate developer and consumer roles for each business unit.
• If different control rooms are used for Dev (Test) and Prod, then you may only need consumer roles on Prod, and developer roles on Dev. But see the section below titled “Considerations for Multiple Control Rooms” for a more detailed discussion of this.

Business Unit Folder Roles

Create security roles to provide your users access to the various business unit folders you created. Roles will be organised alphabetically in the control room listing. To keep roles related to each business unit together, the name of each role should begin with the business unit, for example “Finance – Bot Consumers”.

For a role for consumers of bots, check the options to “View my bots” and “Run my bots” under the BOTS section. When you create a role for developers, check the additional options that you wish to allow developers to perform.

When you check the option “View my bots” the Bots tab will be enabled (see below). For a role for consumers of bots, check the options against the relevant folders which allow them to Run and View bots. When you create a second role for developers, check the options against the relevant folders that you wish to allow bot creators to perform.
 

For proper separation of duties and secure platform governance you should assign unattended bot runner users to specific business units using the business unit folder roles. This is because unattended bot runner users will have access to system credentials, and just like a human users you do not want digital users to have credentials for every single business system. When you setup your bot runner users you should assign them to business units on the Run as section of the role. In the image below you can see that only the Finance worker runner is assigned to the Finance department role. 

Reusable Logic Folder Role

The Reusable Logic folder will only be used by bot developers. Changes to these bots can adversely affect all bots that reference them. Therefore, changes should be tightly controlled and only the CoE should be responsible for maintaining these components. Business unit bot developers should only be able to Clone these components for bot development purposes.

• Create a custom role to enable members of the CoE to have at least Check in and Check out rights over this folder. 
• Create a custom role to enable all business unit developers to have the rights to Clone bots from these folders.

It is likely that certain reusable bot components will apply to some business units but not others. It is not necessary to secure individual sub-folders under Reusable logic, as even if developers in a business unit can access the logic, they cannot access the credentials to use the logic against business systems.
 

Organisation Wide Folder Role

If you created a folder for bots which are used across the organisation, then you will need a folder role to grant users access to this folder. Members of the CoE would generally be responsible for maintaining these bots.

• Edit the CoE bot developer role created above for the Reusable Logic folder and grant at least Check in and Check out rights over the Company Wide Bots folder. 
• Create a custom role to enable all attended bot runner users to have the right to Run bots from this folder.

Credential Lockers

Credentials for the different systems which bots will access should always be stored in the credential vault rather than in variables or hard coded into bots. Note that where you use Singe Sign On (SSO) for accessing business applications, the user’s network credential may lead them straight into business applications. For those applications it is not necessary to configure credentials in the credential vault.

• Credentials are assigned to credential lockers, which allow you to configure which users can access and use the credentials. An example might be “HR Credentials”.
• Within a credential locker there can be credentials for multiple applications, with each application configured as a credential. An example might be “Workday”.
• A single credential can have multiple attributes. An example might be “username” and “password”
   

You should setup a credential locker for each business unit that needs to control access to their own application credentials.
Below are the high-level steps to setup a credential vault. 

1. Click to create a credential locker and give it a name, e.g. HR Credentials.
2. Assign Owners and Managers. These will most likely be members of the Automation CoE.
3. Skip locker participants. There is no need to assign specific user accounts.
4. Setup locker consumers. Locker consumers can enter their personal values for credential attributes (e.g. their own specific username and password) and can use those credentials when running bots. Locker consumers are assigned via roles. When restricting access to credential vaults you can use the business unit folder roles that you previously created.
    

Setup Users

You will need to create user accounts for the Human Users who will access the platform, as well as for your Digital Workers (i.e. unattended bot runners) who will use unattended bot runner licences. 

Human Users

You will need to setup a user account for each human user who will either use automations, build automations, or administer the platform. Licences generally must be assigned to human users to provide access to functionality within the platform. Some user types will not need a licence assigned however. Admin users for example do not need a licence to administer the platform, they only need the AAE_Admin role assigned. 

Licences are assigned to a human user to entitle them to access certain functionality. For example, a user who will create bots will need to be assigned a bot creator licence. For each licence assigned you will also need to assign a role to determine the extent of the functionality that the user can access. This will determine which menu items and options the user can see within the control room. Custom roles can be created for this purpose, however for an initial configuration it is recommended that you use the System roles that are provided. These roles all begin with “AAE_”. For a bot creator user you would assign the “AAE_Bot Developer” system role.

Roles also need to be assigned to human users to grant them access to folders containing bots. The business unit folder roles will provide access to the folders and credential lockers they need, as well as the unattended bot runners (i.e. digital workers) they can use.
 

Digital Workers

Digital workers will need a user account within the control room to enable an unattended bot runner licence to be assigned, and for roles to be assigned to unlock functionality and folders of bots for them to access. Digital workers will also need computer credentials to logon to a computer to run bots. 

• It is recommended to embed the business unit name at the start for digital workers belonging to a specific business unit. For example: Finance_WallE, Finance_Robby, Finance_Robocop. This allows multiple workers to be more easily chosen when creating a schedule for an automation, as related digital workers will appear together. 
• The simplest configuration involves assigning a specific computer to each digital worker, entering the credentials for that computer into the user record, and ensuring no other user account has the same default device. 

Assign the AAE_Basic role to each digital worker. Also assign the relevant folder roles created earlier to grant access to the folders they will need to access. The business unit folder roles will also grant access to the relevant credential lockers required to work in that business unit. You must also assign an unattended bot runner licence so that they can run bots in unattended mode.
 

User Credentials

After your users have been setup they will need to enter credentials into the credential vault for the systems which will be automated. Human users who will run bots on their own computer (attended bot licences) will need to navigate to the control room and enter user-provided attributes into the lockers they have been assigned. Unattended bot runners will require someone to perform this action on their behalf.

Considerations for Multiple Control Rooms

If you have separate production, development and testing control rooms then folders and roles will need to be setup across each of the control rooms.

• Credential lockers and credential names should be consistent across control rooms, although the values entered will likely be different. This enables easy migration of automations between control rooms.
• Consumers of bots should only have access to the Prod control room, to run bots approved for production use cases. Folder roles that provide consumer only access to folders are not required on Dev and Test control rooms.
• Bot development will only occur on the Dev control room. Roles that provide creator access on folders will not be required on Prod and Test control rooms.

However: A bot creator licence may actually be useful on the Prod control room, to enable the CoE to review logic and make small changes as part of deployment. If there is no creator licence on Prod you will need to import bots directly into the Public folder, which means the bot can immediately be accessed by consumers. 

Some customers may combine Dev and Test activities on a single control room. Given there is a clear delineation between automations in Private and Public folders, this already provides a clear delineation between Dev (Private) and Test (Public) activities. If using a combines Dev/Test control room you will need both creator and consumer versions of the folder roles on your control room.
 

Considerations for Single Control Room

Managing the bot lifecycle is more difficult with a single control room. The only ‘stage-gate’ to validate that a bot is ready for production is when it is checked into the Public folder. The bot creator must therefore fully test the bot while it is in development mode. Bot creators must check their own bots into the Public folder, as only they can see the contents of their Private folder. This means there is no ability to separate responsibility for building bots and deploying them to Public with a single control room.

You can however limit the ability to schedule a bot to only certain users. The AAE_Bot Developer role does not allow scheduling of bots, which means a user with higher privileges (eg. AAE_Admin) would be needed to schedule bots. An additional review of unattended bots can therefore be performed before they are scheduled. This is not possible with attended automations, as they will immediately be visible to users once checked into the Public folder.