Your automation practice might involve a lot of people, technologies, and data. To ensure the right people have access to the right parts of an automation, you'll want to carefully and thoughtfully set up security in Appian RPA.

This page describes how to secure the components of a robotic task, as well as the data that flows into and from Appian RPA. It also covers how to set up security between robotic tasks and other application objects.

How do permissions work in RPA?

In Appian RPA, you'll use permissions to secure users, robots, and robotic tasks. Appian RPA uses a flexible permissions mechanism based on tags. These tags:

• Allow users to access robots
• Allow users to access robotic tasks
• Define which robotic tasks can be executed on each robot
• Define which queues a robotic task can act on
• Define which credentials can be used with a robotic task

The tag-based permissions system enables you to assign a combination of robots and robotic tasks to one or more users, as well as use credentials with them. Different users can access the same robotic task, robot, queue, or credential no matter what their role is — they just need to share a tag with that component.

It is very important to keep in mind that any permission changes, on any component in the console, can make a user lose access to a robotic task they've created, or prevent that user from executing or editing a robotic task. For this reason, it is important that you carefully consider any permission changes you perform from the console.

Automation vs. application security

You'll set up security in RPA differently than you may be used to in setting it up in your applications. Refer to the following table to understand the key differences.

	Application	Automation
Where you assign permissions	Objects	Objects
Users or groups	Both	Users
Permission levels	Viewer, Editor, Administrator, Deny	Regular or mandatory
Inheritance	Depends on the object	No
Object visibility	Controlled separately	Controlled by permissions

Types of permissions

There are two types of permissions in Appian RPA:

• Regular permission: Regular permissions are granted by tags that don't end with an exclamation mark. These permissions don't rely on any other permissions. Any components sharing at least one permission will be able to see each other.

  • For example, if a user, robot, and a robotic task share the operations permission tag, the user can see both the robotic task and robot. Further, the robotic task can execute on that robot.

    

• Mandatory permission: Mandatory permissions are also granted by tags, but end with an exclamation mark. If more than one mandatory permission tag is present, the component can only see or access other components that have all of their same mandatory permission tags.

  • For example, if a user, robot, and a robotic task share the operations! permission tag, but the robot also includes an hr! tag that the user and robotic task don't have, then the user and robotic task won't be able to interact with the robot. The user and the robotic task can interact with each other, though.

    

To make a user, robotic task, robot, queue, or credential visible to another component, both must share at least one permission tag. If a component has more than one mandatory permission tag, the components must share all mandatory permission tags.

For a more thorough example, consider the following components and their permissions:

Component	Name	Permission tags
User	Abigail	operations, legal!, hr!
User	Zeke	finance
Process	Mailroom	operations
Process	Share sensitive information	finance, legal!, hr!
Robot	PC 003	operations, finance, legal!

Consider the parts of Appian RPA that Abigail and Zeke have access to:

1. Abigail shares the operations permission tag with the mailroom process.
2. Abigail shares the legal! and hr! permission tags with the share sensitive information process.
3. Abigail shares operations and legal! tags with PC 003. However, she can't see PC 003. This is because PC 003 doesn't have the mandatory hr! tag, which Abigail's account has. Abigail would be able to see PC 003 if it had the hr! tag, or legal! and hr! were regular permissions.
4. Zeke shares the regular permission tag finance with the mailroom process and PC 003. Based on his permission tags, these are the only components of Appian RPA he has access to.

Assign or edit permissions

Required role: Developer or Administrator

When you want a user to have access to a robotic task or a robot, they must have at least one permission in common. You can assign permissions to users, robotic tasks, and robots in similar ways.

Based on your role, you can assign permissions as follows:

Assign Permissions To	Role: Operations Manager	Role: Developer	Role: Administrator
Users	No	No	Yes
Robots	No	Yes (if permissions in common)	Yes
Robotic tasks	No	Yes (if permissions in common)	Yes

To assign or edit permissions:

1. Go to the tab where you want to assign or edit permissions. For example, the Users, Robots, or Robotic Tasks tabs.
2. In the table on that tab, locate the user, process, or robot you want to edit.

3. In the Actions column for that row, click the lock icon . The Permissions window displays.

   

4. In this window, select or deselect permission tags. If your role is Developer, the list of selectable tags contains only tags assigned to you. If your role is Administrator, the list contains all tags in your system.
5. (Administrators only) Type the name of a new permission, and press Enter.
6. Click OK to save your edits.

Modify user permissions in bulk

Required role: Administrator

As more people access the Appian RPA console, security is important to consider. Administrators can add or remove permissions for multiple users at once:

1. Go to the Users tab in the Appian RPA console.
2. Find the users whose permissions you want to edit. For each user, check the box in the Sel. column.
3. Click the Permissions icon at the top of the list. In the Permissions window, two fields appear:
   • In all selected users: The permissions in this field are present for all selected users. You can add or remove permissions in this field.
   • In some selected users: The permissions in this field are present for some, but not all, selected users. You can remove permissions in this field.
4. Type a tag in the In all selected users field and press Enter to add the permission to all selected users. If the permission already exists, Appian RPA shows it as a suggestion as you type. Click a suggested permission to add it.
5. You can also remove permissions in either field. Click the X for any tag to remove it from the users who have it.

Modify robot permissions in bulk

Required role: Developer or Administrator

You can also add or remove permissions for multiple robots at one time:

1. Go to the Robots tab in the Appian RPA console.
2. Find the robots where you want to edit permissions. For each robot, check the box in the Sel. column.
3. Click the Permissions icon at the top of the list. In the Permissions window, two fields appear:
   • In all selected robots: The permissions in this field are present for all selected robots. You can add or remove permissions in this field.
   • In some selected robots: The permissions in this field are present for some, but not all, selected robots. You can remove permissions in this field.
4. Type a tag in the In all selected robots field and press Enter to add the permission to all selected robots. If the permission already exists, Appian RPA shows it as a suggestion as you type. Click a suggested permission to add it.
5. You can also remove permissions in either field. Click the X for any tag to remove it from those robots.

Credentials

If a robotic task is tasked with logging into another program or a website, it should use credentials to input the username and password. Credentials store this information securely and retrieve it from the server when needed.

You can use low-code actions to add credentials to your robotic task. Use the Interact with Element method in a robotic task to input credentials in a web browser, or use the Type text method when the robotic task logs into an application. You can also use the Windows Automation module's Interact with Element method to input credentials into Windows applications.

See an example of credentials in a low-code robotic task.

Encryption

All RPA credentials use AES 128-bit encryption, and follow the FIPS Security Model for Cryptographic Modules standard. When credentials are created or updated, they are securely encrypted and stored in a database. The encryption key used for credentials is unique not only to each environment, but also separate from the other keys that are used to encrypt other fields. Each key is stored securely in the Java KeyStore, the password for which is uniquely generated at site startup.

Assign permissions to login credentials

When you want a robotic task to have access to a login credential, the credentials must have at least one permission in common with that component.

To assign or modify permissions to credentials:

1. Go to the Robotic tasks page.
2. Click on the Credentials icon in the toolbar.
3. In the List of credentials, click the Permissions icon in the Actions column.
4. In the window, assign new permissions or remove existing ones in the Permissions field.
5. Click OK.

Securing Appian objects and robotic tasks

If your robotic task interacts with other design objects, you'll need to set up permissions so these objects can be accessed as needed.

Appian RPA uses a different security method than the one you're used to using to secure other objects in your applications. You'll maintain security through permissions you grant to individual user accounts. Developers and operation managers that work in the Appian RPA console will need to share one or more permissions tags with the robotic tasks they need to view or modify. Additionally, service accounts need to share one or more permissions tags with robotic tasks they execute. However, your application users won't need to have permissions configured since they will always be executing robotic tasks in the context of the application, which is through a service account.

Appian recommends that you document your security settings to more easily reproduce in the future. For example, you may need to recreate permissions in a target environment when you deploy a robotic task.

To set up common security Appian RPA and other design objects:

1. Create a service account for Appian RPA and make sure it has either administrator or developer permissions throughout Appian. The service account is automatically added to the user list in Appian RPA.
2. Create the RPA connected system.
3. An Appian RPA administrator should apply permissions to the service account as needed to access the intended robotic tasks and robots. Alternatively, a service account can be designated as an Administrator so it has universal permissions.
4. In your application, add the service account to the appropriate security groups so it can interact with design objects as needed.

Example

To demonstrate how permissions work between Appian RPA and other design objects, we'll use an example:

Suppose your robotic task executes within a process model that processes internal transfer requests. The process model is in an Appian application called RP_Company Transfers. The robotic task will interact with the PeopleSoft user interface to gather data about the employee who requests a transfer and then send it back to the process model to write it into the datastore. The application has three security groups: Administrators (with admin privileges), HR Managers (with editor privileges), and All HR Users (with view privileges).

You create a service account to set up the RPA connected system. You want this service account to be able to write data to your datastore. The datastore's security currently lists HR Managers as editors, so you could add the service account to the HR Managers group to inherit this security, as well as the security of other objects configured for this group.

In the RPA console, you'll set up permissions so the service account can access the robotic task that gathers the data from PeopleSoft. The service account needs to share a permission with the same process. Alternatively, if you make the service account an Administrator, it will have universal access.

Securing data in a robotic task

Robotic tasks access machines, software, and data in ways similar to your human workforce. It's crucial to embed data privacy and security during the design, execution, and review stages for every robotic task. When designing a secure robotic task, consider how Appian stores or shares data and how the robotic task stores execution metadata. RPA's advantage is the ability to interact with multiple systems, so it's also important to know that some security aspects fall outside of Appian's control.

This section describes data security aspects you should consider in the design, execution, and review of robotic tasks.

Designing a robotic task

Developers can include logging in the robotic task code to record information in the execution log, which is helpful for debugging processes or making results more readable. Be mindful of including potentially sensitive information in this log. Users with access to the robotic task will also be able to see execution logs. Never log personally identifiable information (PII), protected health information (PHI), decrypted values, or passwords as plain text.

Executing a robotic task

Any data that is written to Appian Cloud databases during the execution of a robotic task adheres to our existing data privacy and retention standards.

Data flow from Appian

If your robotic task accesses existing data in an Appian database, consider where that data will be used and how it might be stored elsewhere. For example, if you use a robotic task to send Appian data to your HR system, you'll need to evaluate that software vendor's data privacy and storage practices prior to deployment.

Additionally, it's important to regularly evaluate and monitor the security of the robots where your robotic tasks are being executed. Consider who has access to files that the robotic task regularly generates, updates, or moves on these robots. If the files contain sensitive information, consider cleaning or removing the files appropriately.

Data flow to Appian

On the Appian side, if the robotic task is executed as part of a process model, any data passed back from the robotic task may be stored in the Process Details area during monitoring. Administrators should consider who has access to the application and process models if this data is sensitive and shouldn't be easily accessible.

You may also configure your robotic tasks to write or retrieve information in other databases. However, this type of access falls outside of Appian's security perimeter, and implementation must be tested for security independently.

Viewing results

You can control the information the will be captured when manually executing a robotic task through the console. In the Execution options, choose to record the execution and take screenshots along the way. If you're concerned about the information contained in the execution video or screenshot, disable these options when manually executing the robotic task.

However, there are robotic task actions that enable you to take screenshots during execution, which could override the manual execution option. Communicate with developers to ensure security concerns and guidelines are also respected in the robotic task code.

Execution results (including video and images, if captured) are visible to users who share permissions with the robotic task, so administrators can configure security by adding or removing permission tags as necessary.