Unifying Appian RPA with Appian Designer

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 above and RPA version to 9.3.0 or above starts the changes described on this page. Let's take a look at what's changing, what's temporary, and what has not changed yet as of the Appian 23.4 release.

Robotic tasks

Where to find robotic tasks

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.

What to do next

1. Add existing robotic tasks to your existing application(s) or create new robotic tasks.
2. Update robotic tasks to use security role maps. Existing robotic tasks inherit their current permission tags, but a system administrator should update them to use security role maps. Basic users who are not system administrators cannot see robotic tasks in Appian Designer until you complete this task.

Important notes

• New robotic tasks use security role maps exclusively for object security, even though the permission tag field remains. Permission tags continue to determine which queues and credentials can be used with this robotic task.
• The same robotic tasks in different environments will have the same UUID. They are treated as existing objects when changes are made and deployed.
• In the appian 23.4 release, a new version of the Execute Robotic Task smart service was released and now you can configure robotic tasks directly in the process node, eliminating the need for connected systems and integration rules. You can still use your existing connected system and service account, but we recommend simplifying your applications by using this updated smart service.

Robot pools

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.

Where to find robot pools

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.

What to do next

1. Following the permission tag 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.
2. Add robot pools to your existing application(s) or create new ones. You must manually add robots to robot pools per environment.

Important notes

• The same robot pools in different environments will have the same UUID. They are treated as existing objects when changes are made and deployed.
• When you import and export robot pools, individual robots assigned to those pools are not included.
• To understand more about adding robots to robot pools, please see the Robot Pools page.

Robot management

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.

Important notes

• As part of this transition, Robot management is still temporarily available in the RPA console at this link: 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.
• If you want your operations manager to see all robotic task executions, make sure you add them as a viewer to the security role map for robotic tasks that use security role maps.
• If you are using Appian 23.3 or earlier, Permission tags still control user access to robots. However, use robot pools to specify which robotic tasks each robot can run.
• In the Appian 23.4 release, there was a change in how robot security is handled. Before this release, robots were secured using permission tags. However, starting from the Appian 23.4 release, newly created robots can only be secured using role maps.

  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.

Permission tag migration

Overview

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.

Migration process

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:

1. Appian creates a robot pool for each unique permission tag assigned to a robotic task and at least one robot.
2. Appian ignores tags on robots if the tag isn't associated with any robotic tasks.
3. Robots sharing the same permission tag become members of the same pool.
4. Appian assigns the robot pool to the robotic task as part of the migration process.

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.

Examples

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

Post-migration maintenance

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 also

See the Security page for information about how permission tags work in RPA.