This page describes how permissions are used to secure users, resources, and robotic processes in Appian RPA. It also covers how to set up security between Appian and Appian RPA. To learn how to protect the data that flows through Appian RPA, check out Securing Data in a Robotic Process.
Looking for a refresher on these components? Check out key terms in Appian RPA.
Appian RPA uses a flexible permissions mechanism based on tags that can be used to:
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, 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.
To make a user, robotic process, resource, or credential visible to another component, both must share at least one permission. If a component has more than one permission tag ending in an exclamation mark, the components must share all mandatory permissions with this mark.
There are two types of 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|
|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 ensure 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. 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.
See an example of credentials in a low-code robotic process.
Never store usernames, passwords, or other sensitive information as plain text.
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 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:
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.
On This Page