The capabilities described on this page are included in Appian's standard capability tier. Usage limits may apply. |
There are some important changes happening to Appian RPA: we are transitioning from using the Appian RPA console to the powerful and familiar Appian Designer. After careful evaluation and listening to feedback from users, we've decided that the Appian platform is a better fit for Appian RPA and its evolving features. This transition is thoughtfully planned out and designed to cause minimal disruptions, while providing major benefits. It's important to know that this transition will span several releases, but we're here to guide you along the way.
Upgrading your Appian environment to version 23.3 or higher and RPA version to 9.3.0 or higher starts the changes described on this page. For access to additional features in the Operations Console and the enhanced Execute Robotic Task smart service, which allows direct configuration of robotic tasks within the process node, upgrade your Appian environment to version 24.1 or higher and Appian RPA 9.8.0 or higher.
Tip: As a best practice, we recommend you always upgrade to the most recent version of Appian RPA when upgrading Appian. For more in-depth information about Appian and Appian RPA compatibility, see the About Releases and Upgrades page.
Let's take a look at what's changing, what's temporary, and what has not changed yet.
After the upgrade, system administrators can locate robotic tasks in the Objects view in Appian Designer. Basic users can continue to use the RPA console until your robotic tasks are updated to use security role maps.
Robot pools are a new design object, as of Appian 23.3, that enables you to group robots based on their unique roles and capabilities. When you're creating or managing a robotic task, you can choose the appropriate robot pool responsible for executing the task. Any available robot in the pool can now execute the robotic task, ensuring that it is performed by an available robot in the assigned pool. Robot pools are secured using security role maps.
After the upgrade, you can find your robot pools in the Objects view in Appian Designer.
During the upgrade, Appian automatically creates robot pools for existing robots assigned to robotic tasks. See the following section on Permission tag migration for detailed information about this process.
The management of your robots has moved from Appian RPA to a new workspace called the Operations Console. The Operations Console will also host future enhancements for managing robots.
https://your-environment.com/rpa/nodes.xhtml
. Remember to replace "your-environment.com" with the appropriate environment name. We'll be sure to let you know well ahead of time when this temporary period is nearing its end.Note: If you are using Appian 23.4 or later, you can permanently switch your robots from using permission tags to role maps. Please be aware that this process is not automatic and requires you to complete the manual steps.
Upgrading your Appian environment to version 23.3 or above, and RPA version 9.3.0 or above, kicks off the permission tag migration. The migration process only happens once and only applies if you created robotic tasks in previous versions of Appian RPA. This section describes what happens during the migration and the end result.
The tag migration process converts permission tags, used for assigning robots, into Robot Pools. Robot Pools are automatically created during this process to ensure all robotic tasks continue to execute on their designated robots.
Here is how it happens:
The migration process applies the following rules when there are mandatory permission tags.
If a robotic task… | Then the migration process… |
has no mandatory tags |
creates a robot pool for each non-mandatory tag. Each robot that shares the non-mandatory tag and has no other mandatory tags is added to the pool. |
has mandatory tags | creates a robot pool with the name of all assigned mandatory tags. If multiple mandatory tags are present, the name of the robot pool is a concatenation of all the tags. Only robots that contain all of the same mandatory tags as the robotic task are added to the robot pool. |
Here are some examples of what the Robot Pools look like after migration.
Example A
In this first example, we have one robotic task and four robots before the migration.
Robotic Task | Tags |
Robotic Task | operations and finance |
Robots | Tags |
RobotOps | operations |
RobotFinance | finance |
RobotOpsFin | operations and finance |
RobotOpsFinHR | operations , finance , hr! |
After the migration, there are two robot pools. Notice that the RobotOpsFin robot belongs to both pools and that the RobotOpsFinHR robot is not included because it has a mandatory tag.
Robotic Task with Tags… | Creates Robot Pools… | With Robot Pool Members |
operations and finance |
operations and finance |
operations: RobotOps and RobotOpsFin finance: RobotFinance and RobotOpsFin |
Example B
In this second example, there's a robotic task with three tags, two of which are mandatory. And there are four robots.
Robotic Task | Tags |
Robotic Task | operations , hr! , and legal! |
Robots | Tags |
Robot HR | hr! |
Robot HRLegal | hr! , legal! |
Robot HRLegalMarketing | hr! , legal! , and marketing! |
After the migration, there is one robot pool. Since robots must have all of the same mandatory tags as the robotic task to be added to the robot pool, only one robot became a robot pool member.
These mandatory Robotic Task Tags… | Become Robot Pool… | With Robot Pool Members |
hr! , and legal! |
hr!legal! |
hr!legal!: Robot HRLegal |
Following the migration, you may notice a lot of robot pools, potentially more than necessary. Be sure to review and modify these robot pools to ensure they match your requirements.
See the Security page for information about how permission tags work in RPA.
Unification Guide