|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 robotic processes and other application objects.
Looking for a refresher on these components? Check out key terms in Appian 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:
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.
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.
|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|
There are two types of permissions in Appian RPA:
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.
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:
|Process||Share sensitive information||
Consider the parts of Appian RPA that Abigail and Zeke have access to:
operationspermission tag with the mailroom process.
hr!permission tags with the share sensitive information process.
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!were regular permissions.
financewith the mailroom process and PC 003. Based on his permission tags, these are the only components of Appian RPA he has access to.
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|
|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:
In the Actions column for that row, click the lock icon . The Permissions window displays.
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:
Required role: Developer or Administrator
You can also add or remove permissions for multiple resources at one time:
If a robotic process 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 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.
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:
If your robotic process 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 processes they need to view or modify. Additionally, service accounts need to share one or more permissions tags with robotic processes they execute. However, your application users won't need to have permissions configured since they will always be executing robotic processes 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 process.
To set up common security Appian RPA and other design objects:
To demonstrate how permissions work between Appian RPA and other design objects, we'll use an example:
Suppose your robotic process executes within a process model that processes internal transfer requests. The process model is in an Appian application called RP_Company Transfers. The robotic process 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 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.
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.
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. 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.
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.
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.
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.
You can control the information the will be captured when manually executing a robotic process 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 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.
On This Page