Differences in Automation 360 and Enterprise 11/Enterprise 10 features

Review how some features and functionalities, such as folder structure, bot deployment, packages, variables, and MetaBots, are different in Automation 360 as compared with Enterprise 11 and Enterprise 10.

Folder structure

The folder structure in which bots (Task Bots and MetaBots) are stored in Automation 360 is different compared with Enterprise 11 and Enterprise 10.

Automation 360 folder structure: The bots (Task Bots and MetaBots) are available in the Automation > Bots. Bots that are migrated from Enterprise 11 or Enterprise 10 are available in the public workspace.
The following image shows the folder structure in Automation 360
Enterprise 11 and Enterprise 10 folder structure: Bots (Task Bots only) are available in the My Tasks folder (Automate > Tasks > My Tasks) and MetaBots are available in the My MetaBots folder.
The following image shows the folder structure in Enterprise 11:

Bot deployment

Enterprise 11 : When a low-priority bot is running and a high-priority bot is deployed, the system pauses the low-priority bot and runs the high-priority bot. After the high-priority bot is run, the low-priority bot resumes.
Automation 360 : The priority of bots is verified at deployment. When bots are queued for a Bot Runner user, higher-priority bots are deployed before lower-priority bots. However, if a lower-priority bot is already running, the higher-priority bots are deployed only after the lower-priority bot completes running.

Packages

For most of the Enterprise 11 or Enterprise 10 commands, similar or equivalent actions and packages are available in Automation 360. However, the behavior of some of the Automation 360commands is different compared with those in Enterprise 11 or Enterprise 10.

Automation 360 is created afresh to support not only the current but also the future automation needs of modern enterprises. Accordingly, Automation 360 is built to meet important objectives, such as providing the following features:
- A standardized, predictable, and scalable platform
- Consistent user experience
- Improved flexibility and security
With Automation 360, we aim to provide these features by employing industry-standard exception handling, rich support for dedicated data types, and so on.
Because Automation 360 is created afresh, some of the Enterprise 11 capabilities that have been redesigned in Automation 360 might not have a directly corresponding Automation 360 feature.

However, to ensure that the migrated bots produce output that is identical to that produced by their corresponding Enterprise 11 bots, we have mapped Enterprise 11 commands to their corresponding actions in Automation 360.

In instances where a direct mapping between an Enterprise 11 command and an Automation 360 action is unavailable, we have used "expressions" to ensure that the migrated bots produce output that is identical to that produced by their corresponding Enterprise 11 bots, without requiring you to manually update the bots.
Note: The usage of expressions leads to more number of lines and additional variables in the migrated bots as compared to their corresponding Enterprise 11 bots.

For information about expressions, see Legacy Automation package.
For Enterprise 10/Enterprise 11 command using a windows title field configured with a user defined variable, the migration process migrates the bot by adding the Set Title action just above the respective command. Automation 360 does not allow user variables in the Windows Title field. Use the Set Title action to achieve the same behavior.
In Enterprise 11, when a bot contains more than one command with the resize window option selected, the window is resized to the dimensions specified by the first command. In Automation 360, the window is resized each time the bot encounters an action with the resize window option selected. This ensures that at runtime the window dimensions of each action match the dimensions at which that action was configured, which enhances the bot's ability to find the object.
In Enterprise 11 or Enterprise 10, loop indexing of table starts with 1 and increments by 1. Automation 360 starts indexing with 0 and increments by 1.
The migration process migrates IF and Loop commands that contain multiple conditions of a variable.
Disabled commands are migrated as follows based on the different coding patterns:
- An individually disabled command (with or without any validation error) is migrated as a disabled action. All actions are disabled if one disabled command is migrated to multiple actions in Automation 360.
- Disabled Error Handling command is migrated to disabled try and catch block including all other actions depending on its configuration.
- Disable Loop command is migrated to a disabled Loop action in Automation 360.
- Disabled If command is migrated as a comment so that the migrated bot returns the same result as that returned by the corresponding Enterprise 10 or Enterprise 11 bot.

In Enterprise 11 or Enterprise 10, some String operation commands use Tab, Enter, and Separator special characters. In Automation 360, these characters are system variables in the String package.


Enterprise 10/Enterprise 11	Automation 360
[Tab]	$String:Tab$
[Enter]	$String:Enter$
[Separator]	$String:Separator$

See String package.

Enterprise 11 or Enterprise 10 provides various presets as part of the windows title selection and they are migrated to respective presets in Automation 360.


Enterprise 10/Enterprise 11 Options	Automation 360 Options
Current Active Window	Current Active Window
Desktop	For the Insert mouse click command, use the Screen for window title option. For the Insert keystroke command, use the Current Active Window option. For Screen > Capture area, use the Screen for window title option. For the Capture Desktop command of the Screen Capture command, use the Capture area action of the Screen package with the Screen option selected from the list available in the Application tab.
Wallpaper	Desktop
Taskbar	Taskbar

Package mapping for migration

Variables

For most of the Enterprise 11 or Enterprise 10 user, system, and credential variables, similar or equivalent system variables are available in Automation 360. The behavior of some of the Enterprise 11 or Enterprise 10 variables is different compared with Automation 360.

For each variable passed as input in Enterprise 11 or Enterprise 10 bot, a line is added in the migrated bot in Automation 360. For example, if you are passing 100 variable as input in Enterprise 11 bot, after migration that bot has 100 new lines.
In Enterprise 11 or Enterprise 10, you can use the Session Name field in paired commands to specify a session name as both a static value and a variable value. For example, you can specify a session name to open a file or establish a connection. You can then use that same session name as a variable value in a Loop command. However, migrated bots differentiates between a static value and a variable value, and handle the values differently after migration. As a result, after you migrate these bots to Automation 360, you must update the bot to use the correct output Dataset variables in the Loop command (which is aligned with the Open file session variable). For migrated bots, we recommend that you configure the session name as a static value or a variable value in all the instances.
Enterprise 11 or Enterprise 10 commands that store the return values to the $Clipboard$ system variable are not supported in Automation 360. When you migrate bots with this functionality, the migration process assigns the values to a temporary variable and then assigns the value to the Automation 360 $System:Clipboard$ system variable by adding the Copy To action to the Clipboard package.
Some commands return values to variables for further processing. In Enterprise 11 or Enterprise 10, users can store these values in different types of variables, where as in Automation 360, these values are stored in a specific type of variable only.
For example, if a command returns a value to an array for a specific cell, then in Automation 360, we store the value in a temporary string variable. Then in the next action, we store this temporary value to an actual array variable to enure that the bot execution logic stays intact.
In Automation 360, the single dollar sign ($) is reserved for Automation Anywhere use, so all user entries of a single dollar sign are automatically replaced with two dollar signs ($). For example, if you have a text field, "Pay $5.00", we convert that field to read "Pay $5.00" in Automation 360 for it to display properly to users.

In Enterprise 11 or Enterprise 10, bots can use a variable to specify the child bot you want to run. In Automation 360, the task path is updated to the Bots folder. The following table provides a few examples:


Enterprise 11/ or Enterprise 10	Automation 360
D:\My Documents\AAE_V11\Automation Anywhere Files\Automation Anywhere\My Tasks\Migration\$bot_name$	Bots\My Tasks\Migration\$bot_name$
$AAApplicationpath$\Automation Anywhere\My Tasks\Migration\$bot_name$	Bots\My Tasks\Migration\$bot_name$
D:\$UserName$\My Documents\AAE_V11\Automation Anywhere Files\Automation Anywhere\My Tasks\Migration\$bot_name$	Bots\My Tasks\Migration\$bot_name$
D:\My Documents\AAE_V11\Automation Anywhere Files\Automation Anywhere\$bot_path$\$bot_name$	Bots\My Tasks\$bot_path$\$bot_name$

Variable mapping for migration

Variables support

MetaBots

MetaBots are not available in Automation 360. When you migrate Enterprise 11 or Enterprise 10 MetaBots, they are migrated to equivalent Task Bots in Automation 360. These Task Bots provide similar output and capabilities of the MetaBots.

The migration process migrates the DLLs and logic to equivalent bots. The Run Logic command is converted to the Run action of the Task Bot package. The DLLs in the MetaBots use the Execute command to run a function from that DLL. After migration to Automation 360, each Execute command is converted to Open, Run function, and Close actions of the DLL package. Information about which function to run from the DLL, which parameters to use, and other details in the Execute command is migrated to the Run action. MetaBots with DLLs that use credential variables of string, character, and Byte data type can be migrated to Automation 360.

Earlier to Automation 360 v.17, the dictionary variable was used to provide input parameters in a migrated bots which used to add additional steps in the bot. Starting from v.17, the Entrylist variable is used to provide input parameters in a migrated bot. This reduces the number of steps added to the migrated bot.

How MetaBots are migrated