| This content applies solely to Appian RPA, which must be purchased separately from the Appian base platform. |
A robot is a digital worker that's made up of two parts: a host machine and an agent. A robot needs a workspace, just like a human worker does. The host machine is the environment in which the digital worker completes robotic tasks. The host machine can be a physical machine, such as a separate computer, or a virtual machine on a cloud server.
To execute a robotic task, the robot needs certain data or information from the server. The robot communicates with the server through an agent, which is a file you install on the host machine. Agents must be up and running on the host machine for robotic tasks to execute properly and communicate the results back to the console.
This page describes the Robots tab in the Appian RPA console, which you can use to set up and monitor robots.
Required role: Administrator
Create a robot for each physical or virtual machine (VM) that will run robotic tasks. Every robot has a corresponding agent, which can only be used on one host machine.
Multiple robots can map to the same host machine. For example, if you connect your personal computer to both your development and staging environments for testing purposes, you will create two robots.
Avoid trying to run multiple robotic tasks on the same machine at the same time because they will likely conflict with each other.
When running your robotic tasks in a production environment, we recommend using a dedicated machine, whether it is a provisioned virtual machine (VM) or physical machine.
To add a robot:
. The Robot definition editor page displays.To execute a robotic task for a new robot, remember to install the agent on the host machine. The agent is also required to communicate other information between Appian and the host machine, such as the robot's status.
Be sure to add the host machine(s) to your Appian environment's firewall allow list, if applicable. The robotic task may not be able to execute successfully if the firewall blocks communication between the agent, host machine, and server.
You can use a VM to run robotic tasks. By default, VMs may timeout and become unavailable after a period of inactivity. To ensure the VM remains available, you may want to complete additional configuration when creating a VM host machine.
Microsoft Remote Desktop users can configure the following to prevent VM host machines from timing out:
Additionally, ensure that the agent you have downloaded on the host machine has administrator privileges to allow them to unblock sessions as needed.
Required role: Any
The List of robots contains all robots available to you. Click a robot to view its details.
The robots are listed in alphabetical order in a grid with the following information:
For each robot in the list, you'll see a status to indicate what the robot is currently doing.
| Status | Description |
|---|---|
| Online | Robot is online and ready to run a robotic task. |
| Standby | Robot is ready to run a robotic task. |
| Running | Robot is online and busy running a robotic task. |
| Recording | Robot is online and busy recording interactions. |
| Offline | Robot is offline and can't run a robotic task. Run the robotic task on your local host machine or allow Appian to sign in to the robot automatically. |
| Disabled | This robot is disabled, so it can't run robotic tasks. Enable the robot to run a robotic task. |
| Concurrence | The robot is using an agent that's been installed and launched in more than one place. Disconnect one agent and allow Appian to sign in to the robot automatically. |
| Blocked Keys | There is an issue with the keys on the robot. A robotic task can run, but may produce unexpected results. To fix the issue, run a robotic task to release the keys, or restart the user session. |
| Outdated | The agent is updating or failed to update. Check back soon. If still outdated, manually reinstall and launch the agent. |
You can perform several actions from the list of robots. Available actions depend on the robot's connectivity and status.
Additional actions are available from the Robot detail page.
| Icon | Description |
|---|---|
 |
Disables a robot |
 |
Enables a robot |
 |
Removes the user session currently associated with the robot. This action is useful when the user session doesn't exist anymore, but the console hasn't refreshed. |
 |
Allows you to assign permissions to the robot. |
Required role: Developer or Administrator
RPA components rely on shared permissions for security. Users, robotic tasks, and robots must have tags in common to see and interact with each other. To assign or edit permissions for a robot, see Assign or Edit Permissions.
Looking to edit permissions for multiple robots? Save time by modifying robot permissions in bulk.
Required role: Any
On the Robot detail page, you can find:
Different actions are available in the toolbar of the Robot detail page, depending on the robot's status.
| Icon | Action | Description |
|---|---|---|
 |
Download the agent | Downloads the agent file associated with this robot. |
 |
Launch the remote-control screen | Available only for Online robots. |
 |
Disable the agent's local plugins | Available only if the agent contains enabled plugins. |
 |
Enable the agent's local plugins | Available only if the agent contains disabled plugins. |
 |
Lock input from the host machine's keyboard and mouse | Available only for Online robots. The agent must be installed on the host machine using an administrator profile. |
 |
Unlock input from the host machine's keyboard and mouse | Available only for Online robots. The agent must be installed on the host machine using an administrator profile. |
 |
Send an agent for remote debugging | A new agent is downloaded on the host machine, specifically designed for debugging remotely when you cannot debug directly on the port involved. |
 |
Execute the agent for remote debugging | Launch the agent to begin remote debugging. |
 |
Stop the agent from remotely debugging | Only on the host machine under remote debugging. |
 |
Execute the agent for remote debugging (JJDWP) | This debugging is less common and requires its own execution setup. If you select this action, Appian will ask you for the IP, port and timeout for the connection. |
 |
Stop the agent from remotely debugging (JJDWP) | Unlike the non-JJDWP version, this debugging must be stopped from the console, and not from the host machine being debugged. |
 |
Restart the agent | Restarting the agent can prevent, among other things, low memory problems on the host machine where it is running. |
 |
Permanently remove the robot from the console | This action cannot be undone. Available for administrator roles only. |
Before a robotic task starts, it may need to access your host machine and start a user session if one isn't already active. On top of that, your business may restrict the privileges available to this user session.
You can configure your robot to allow Appian to automatically sign into a virtual machine as any designated user (basic or administrator) in order to start a robotic task. This means that you won't need to keep user sessions active on virtual machines in case a robotic task needs to start. Instead, Appian can start a session as needed for robots with Standby status. Appian can also automatically sign out of the host machine if there are no more robotic tasks to run after the last execution. Configure this option to build more flexibility into your unattended automations.
Appian can only sign in to Windows host machines with this configuration enabled.
You can find these configuration options on the Robot detail page in the RPA console:
In order for the automatic sign-in service to work as expected, several pre-requisite steps must first be completed. These configuration steps and installation will require administrator privileges. Once the service is installed, a robotic task can be executed using a non-admin user. In order for the automatic sign-in service to work as expected, several pre-requisite steps must first be completed. These configuration steps and installation will require administrator privileges. Once the service is installed, a robotic task can be executed using a non-admin user account.
For the service to work as expected, the host machine must use a Windows 64-bit OS (x64-based) and the user account Appian uses to sign in should be configured in the following ways:
To add the user account, go to Computer Management > Local Users and Groups > Groups > Remote Desktop Users.
Local Security Policy > Local Policies > User Rights Assignment:
Allow log on through Remote Desktop Services
Remote Desktop Settings.To allow Appian to sign in:
You need administrator privileges on the robot to install the sign-in service using the instructions below.
After you configure the robot, install the sign-in files on the host machine using the installation wizard:
C:\Users\<username>\AppData\Local. The installer will create a folder titled Appian RPA in this location with all the necessary files.Services. You should see the new service in the list: Appian RPA AutologinService [Host Nachine Name].You are now ready to use automatic sign-in.
When installing the automatic sign-in service, the service is automatically started by the Local System account, which is the predefined local account used by the service control manager. You can change it to be another user if you’d like to use a separate account. This user account does not need administrator privileges.
To modify which account starts the service:
Back in the Appian RPA console, you can test the connection to the host machine remotely. Appian does this through Remote Desktop Protocol (RDP).
If there is an active user session on the robot, Appian may not be able to sign in successfully. For the best results, ensure there is no active user session for the user account Appian uses to sign in to the robot.
If your test was successful, then you're all set! Appian will automatically sign in to this host machine using the provided credentials whenever the robot is called upon to execute a robotic task.
To help keep you on track, Appian may display messages to show you when it's unable to sign in. Use the following table to understand the error and learn how to fix the issue.
| Error message | Reason | Guidance |
|---|---|---|
| Invalid sign-in credentials. Unable to sign in because the credentials are invalid. Check the username and password are correct and try again. | Appian tried to sign into the user sessions using the credentials you provided, but it didn't work. The credentials may be inaccurate, or they don't match an account found on the domain. | Check the domain, username, and password fields to make sure they're correct. |
| Robot not found. Unable to sign in because RDP couldn’t locate the agent on the host machine. Check that the agent is installed on the host machine and try again. | Appian was unable to locate the agent file on the host machine. The agent is required to allow the host machine to communicate with the RPA console. | Check that the agent is installed and that the user account configured to sign in to the host machine has permissions to run the agent. |
| RDP is not enabled. Unable to sign in because Remote Desktop is disabled on the host machine. Enable Remote Desktop and try again. | Appian tried to sign in to a user session on the virtual machine, but RDP isn't enabled. | Enable RDP on the host machine. |
| Error: Active user session. Unable to sign in because the host machine has an active session. Sign out from the active session and try again. | Appian tried to sign in to the virtual machine, but there is already an active user session. Note that this message appears for standard Windows operating systems. |
Sign out of the active user session on the host machine. |
| Error: Active user session. Unable to sign in because the host machine has an active session for the OS user account you’re using to sign in. Sign out from the user’s active session and try again. | Appian tried to sign in to the virtual machine, but there is already an active user session for the user account you're using to sign in. Note that this message appears for Windows Server operating systems. |
Sign out of your active user session on the host machine. |
| Error with automatic sign-in. Unable to sign in because of an issue with Remote Desktop. Review the Remote Desktop settings and try again. | Appian tried to sign in to the virtual machine, but was unable for an unknown reason. | Verify that the RDP settings on the host machine match the configurations listed above. |
| Error with automatic sign-in. Unable to sign in because Remote Desktop didn’t respond. Verify that the sign-in service is running on the host machine and try again. | Appian tried to sign in, but the sign-in service didn't respond in time. It might be that the sign-in service isn't running on the host machine. | Confirm that the sign-in service is running on the host machine. |
| Error: Interactive logon message. Unable to sign in because the host machine has an interactive logon screen. Enable the Skip interactive logon message option on the Robot Details page and try again. | Appian tried to sign in, but the host machine has an interactive logon message. The robot wasn't configured to allow Appian to skip the interactive logon message. | Edit the robot configuration to allow Appian to skip the interactive logon message. |
This feature is deprecated and may be removed in a future release.
In the Container configuration section, you can configure two different types of containers for a robot: Docker and VirtualBox. Once the configuration is done, the console is able to integrate with the container to start and to stop it.
Additionally, it is possible to use Kubernetes as a Docker containers manager.
For Docker, you have to fill the following fields:
Using these configurations, the console generates a Docker command to send to the machine to start or stop it.
For VirtualBox, you have to fill the following fields:
Using these configurations, the console generates a VirtualBox command to send to the machine to start or to stop it.
Required role: Developer or Administrator
You can remotely visualize and operate the desktop where the robotic task is running.
To start monitoring, click on the Monitor icon (
), which will show you a set of icons that allow you to perform certain actions on the desktop where the robot is executing.
| Icon | Description |
|---|---|
 |
Stop monitoring |
 |
Refresh screen |
 |
Take a screenshot |
 |
Full screen |
 |
Request the log file. It allows you to download the local error log. |
 |
Open the scripts editor Groovy. It allows you to execute Groovy code on the client. |
 |
Control remotely. It will show the position of the mouse pointer on screen, allowing you to click and drag elements on the desktop as usual. By enabling it, you will also see a text box where you can send text to the robot as well as the coordinates of the mouse pointer. |
 |
Restart services |
When you're finished monitoring, click the Monitor icon again to stop. The agent consumes more robots while monitoring, so it's important to stop monitoring to ensure performance.
Robotic tasks consume memory and generate artifacts on the host machine during each execution. Over time, this data may start to degrade the host machine's performance. The host machine may benefit from restarting the robot to help free up additional memory.
When you restart a robot, Appian sends a request to the agent to try to restart its connection with the console. You can relaunch the agent from the console or manually restart the agent when you detect any issue with its operation.
You can also restart the robot automatically.
To prevent having too much of your host machine's memory occupied, you can configure a robot's agent to restart automatically when a specified percentage of the host machine's total memory is exceeded.
For example, if the host machine has a 2GB memory, you can set up the agent to restart whenever 80% of the memory is used (1.6GB).
This configuration will trigger an event to restart the agent whenever the reserved memory is exceeded. Events are explained in detail on the Monitoring page.
In the event the server goes down unexpectedly, administrators can configure Appian RPA to disable robots upon restart of the RPA server to ensure robotic tasks do not run until an administrator has verified the robot is in a clean state.
To allow Appian to disable unclean robots on start up:
