Only administrators have access to this tab

The Appian RPA Console allows you to view user information and manage their permissions. Some user properties, such as passwords, are still managed within Appian.

This page describes how authentication works between Appian and Appian RPA. It also covers the information and actions available within the Users tab of Appian RPA.

Appian RPA user types include:

  • ADMIN: Administrators have access to every screen in the console and the ability modify all permissions. It can also create new robots, and has access to every setting available in the Robot setup screen. This user can set up and run all robots available.
  • DEVELOPER: Unlike the administrator, developers cannot access the users screen, and therefore cannot add or delete them. Nevertheless, this user can modify permissions to assigned robotic processes and resources. Developers can also create new robots and have full access to the settings in the Robot setup screen.

Authentication between Appian and Appian RPA

Your permissions within the Appian RPA Console are determined by your role in Appian Designer. If you're an Appian Administrator, you'll have administrator privileges in the Appian RPA Console. Similarly, if you're an Appian Developer, you'll have a developer role in the console. Users with other Appian roles don't have access to the Appian RPA Console.

Although there is a User tab in the Appian RPA Console, the list is read-only. You can't make any changes to user accounts within the console. Instead, you'll need to edit user accounts within the Appian Admin Console or Appian Designer.

A user account is created the first time a user accesses the Appian RPA Console. Appian shares user's account information such as username and password with Appian RPA. When you log in or out of Appian RPA, you're also logged in or out of Appian. The same applies to changing user information or deactivating users in Appian.

Service accounts

To pass data and execute actions in a robotic process, you'll need to set up a service account. The service account role in Appian uses API keys to invoke Appian web APIs. The account isn't able to log into either Appian or Appian RPA, but its credentials are shared to Appian RPA and can be used in the Appian connected system to integrate your application with Appian RPA robotic processes.

The Appian RPA connected system and HTTP connected system objects use a service account to authenticate using an API key. Appian RPA calls back to Appian to lookup the username for that API key in order to authenticate the request. This connection is essential to integrating Appian with Appian RPA, so we suggest establishing the connection early on in your development process.

More on service accounts


Appian RPA developers deploy code to Nexus when developing robotic processes. Nexus doesn't share user information with Appian. Each developer must enter their credentials in a Maven settings file to develop in their local environment and push changes. To allow more users access, you'll need to add users within Nexus. Visit the Sonatype help site for more information.

Appian Module

Appian RPA includes an Appian module that can be used in robotic processes to query info about Appian design objects and execute them. The modules communicate with Appian via internal servlets using authorization tokens that aren't exposed. The module also communicates the username of the person executing the robotic process back to Appian. When the robotic process is in design, the username sent to Appian is that of the user who's currently logged into Appian RPA. When the robotic process is executed, Appian RPA sends the username of the person who initiated the process.

The username varies based on how the robotic process was started.

  • If started in the interface, the currently logged in username is sent to Appian.
  • If started through an integration, the name of the service account is sent to Appian.
  • If started by a schedule, the name of the person who last modified the schedule is sent to Appian.
  • If started through another robotic process, the name of the person to initiate the first robotic process is sent to Appian.

Object security in Appian RPA

Appian RPA objects have a single permissions configuration rather than a security rolemap. Resources, robotic processes, and queues are secured using tags. The user can either select an existing tag or enter freeform text to create a new tag.

Tags are stored entirely on the Appian RPA side and not in Appian. This will require the designer to maintain two different security mechanisms (groups for Appian design objects and tags for RPA objects).

Learn more about securing Appian objects and robotic processes.

User tab in Appian RPA

List of users


Here you can find a complete listing of all users (active and inactive users), including the following information:

  • Login: Appian username used when the account was created
  • Role: the user's profile (ADMIN or DEVELOPER)
  • Active: status of user in the Appian Admin console user. An inactive user cannot access the console.
  • Email: email address where notifications will be sent
  • Full name: User's name and surname(s)
  • Actions: User's permissions administration
  • Permissions: List of permissions assigned to that user
  • Last access: Date of last access
  • Created: Date of creation of the user

Assign permissions to a user

Appian RPA uses a quiet flexible permissions mechanism based on tags that allow users to access robotic processes and execute on resources. You can create new tags or use some of the already available tags.

  1. Click the lock icon 2229048.png
  2. In the window, assign new tags (permissions) or select or deselect existing tags (permissions). To assign a new tag, type a word and hit Enter.


  3. Click OK when finished.

See Security for more information on permissions and how to assign tags to resources and robotic processes.

To manage credentials for robotic processes, see Credentials. With permissions, you can define login credentials for different systems to be reused by all the robotic processes that may require access to those systems.

Open in Github

On This Page