This content applies solely to Appian RPA, which must be purchased separately from the Appian base platform.

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 process, as well as the data that flows into and from Appian RPA. It also covers how to set up security between Appian and Appian RPA.

Looking for a refresher on these components? Check out key terms in Appian RPA.

How do permissions work in RPA?

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

  • Allow users to access resources
  • Allow users to access robotic processes
  • Define which robotic processes can be executed on each resource
  • Define which queues a robotic process can act on
  • Define which credentials can be used with a robotic process

The tag-based permissions system enables you to assign a combination of resources and robotic processes to one or more users, as well as use credentials with them. Different users can access the same robotic process, resource, 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 process they've created, or prevent that user from executing or editing a robotic process. For this reason, it is important that you carefully consider any permission changes you perform from the console.

RPA security is different than Appian security. After you review the key differences, learn how to implement security between your application and automations.

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, resource, and a robotic process share the operations permission tag, the user can see both the robotic process and resource. Further, the robotic process can execute on that resource.


  • 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, resource, and a robotic process share the operations! permission tag, but the resource also includes an hr! tag that the user and robotic process don't have, then the user and robotic process won't be able to interact with the resource. The user and the robotic process can interact with each other, though.


To make a user, robotic process, resource, 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!
Resource 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

Only administrators can create permissions in Appian RPA.

When you want a user to have access to a robotic process or a resource, they must have at least one permission in common. You can assign permissions to users, robotic processes, and resources 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
Resources No Yes (if permissions in common) Yes
Robotic processes No Yes (if permissions in common) Yes

When you import a robotic process, the associated permissions are imported as well. Permissions are not carried during the import and export process for users and resources. Appian recommends first importing a robotic process and then assigning permissions to users and resources. This approach ensures that your process is appropriately permissioned and ensures consistency.

To assign or edit permissions:

  1. Go to the tab where you want to assign or edit permissions. For example, the Users, Resources, or Robotic Processes tabs.
  2. In the table on that tab, locate the user, process, or resource you want to edit.
  3. In the Actions column for that row, click the lock icon 2229048.png. 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 resource permissions in bulk

Required role: Developer or Administrator

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

  1. Go to the Resources tab in the Appian RPA console.
  2. Find the resources where you want to edit permissions. For each resource, 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 resources: The permissions in this field are present for all selected resources. You can add or remove permissions in this field.
    • In some selected resources: The permissions in this field are present for some, but not all, selected resources. You can remove permissions in this field.
  4. Type a tag in the In all selected resources field and press Enter to add the permission to all selected resources. 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 resources.



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

You can use Appian RPA's low-code modules to add credentials to your robotic process. Use the Interact with Element method in a robotic process to input credentials in a web browser, or use the Type text method when the robotic process 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 process.

Never store usernames, passwords, or other sensitive information as plain text. If you use the task recorder to record login actions, remember to always remove the username and password values before saving the recording and update the generated actions to use credentials.


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 process 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 processes page.
  2. Click on the Credentials icon in the toolbar.
  3. In the List of credentials, click the Permissions icon 2229048.png in the Actions column.
  4. In the window, assign new permissions or remove existing ones in the Permissions field. rpa-permission-tags.png
  5. Click OK.

Securing Appian objects and robotic processes

If your robotic process interacts with Appian objects, you'll need to set up permissions so the Appian objects can be accessed as needed. Permissions apply only to service accounts set up to use Appian RPA, since ordinary Appian users don't have access to the robotic processes.

Currently, Appian and Appian RPA have different security mechanisms. You'll maintain security through permissions you grant to the service account that connects the two. 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 process.

To set up common security between Appian and Appian RPA:

  1. Create a service account to communicate with Appian RPA and make sure it has either administrator or developer permissions in Appian.
  2. Once the connected system is set up, the service account will be automatically added to the user list in Appian RPA.
  3. An Appian RPA administrator should apply permissions to the service account as needed to access the intended robotic processes and resources. Alternatively, a service account can be designated as an Administrator so it has universal permissions.
  4. In Appian, the service account can be added to the appropriate security groups so it can interact with Appian objects as needed.


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

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

Let's suppose you create a service account to set up the Appian 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 Manager group to inherit this security, as well as the security of other objects configured for this group.

In Appian RPA, you'll set up permissions so the service account can access the robotic process 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 process

Robotic processes 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 process. When designing a secure robotic process, consider how Appian stores or shares data and how the robotic process 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 processes.

Designing a robotic process

Developers can include logging in the robotic process 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. Appian RPA users with access to the robotic process 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 process

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

Data flow from Appian

If your robotic process 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 process 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 resources where your robotic processes are being executed. Consider who has access to files that the robotic process regularly generates, updates, or moves on these resources. If the files contain sensitive information, consider cleaning or removing the files appropriately.

Data flow to Appian

On the Appian side, if the robotic process is executed as part of a process model, any data passed back from the robotic process 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 processes 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 that Appian RPA captures when manually executing a robotic process through the console. In the Execution options, you can choose to record the execution and take screenshots along the way. If you're concerned about the information that's contained in the execution video or screenshot, you can disable these options when manually executing the robotic process.


However, there are robotic process 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 process code.

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

Open in Github Built: Wed, Aug 17, 2022 (01:05:05 PM)

On This Page