This content applies solely to Appian RPA, which must be purchased separately from the Appian base platform. |
Required role: Developer or Administrator
This page describes how to configure robotic process settings. This configuration is organized into three tabs:
You configure these settings when you create a robotic process. You can change these settings at any time after that.
To configure a robotic process:
From the robotic process configuration page, you can also:
In the Task tab of the robotic process configuration page, you can configure the following settings:
Robotic process variables can store and pass values in your robotic process's workflow, and even between your robotic process and other design objects.
Similar to process variables in a process model, robotic process variables are placeholders for data that can be accessed throughout the lifecycle of a robotic process. These variables can be referenced in actions to display values or to store an action's result value and use it later in other actions of a workflow. You can also set robotic process variables as parameters so they can be used as input fields in a robotic process's execution.
For more information, see Using Robotic Process Variables.
To create a new robotic process variable:
Configure the following fields in the Create Process Variable dialog:
Field | Description |
---|---|
Name | The name of the robotic process variable. Only letters, numbers, and underscores are accepted. |
Type | The data type of the robotic process variable. Robotic process variables can be primitive data types, legacy instructions types, or custom data types (CDTs). The Credential type is used to reserve credentials for use in robotic subprocesses. Note: The following system types cannot be selected for a robotic process variable type: Encrypted Text, Time, complex system data types, and hidden CDTs. See the Data Types page for a complete list of system data types. |
Array (multiple value) | Lets the process variable accept an array of values. You cannot enter an initial value if this checkbox is selected. If your variable is a parameter and you select this checkbox, you can only pass one value when executing the robotic process from the console. To pass multiple list values in your input parameter, use the Execute Robotic Process Smart Service. |
Initial value | The default value of a robotic process variable. Note that you cannot provide an initial value if you select the Array checkbox, if your variable is type CDT, or if your variable is type Date or Date and Time and marked as a parameter. |
Parameter? | Allows process variables to pass values to the robotic process before its execution. If selected, the variable will be used as an input field for the robotic process's execution. Input fields ask a user to provide data before a robotic process is executed. |
Required? | Requires that a parameterized process variable has a value before the robotic process is executed from the Execute robotic process page in the Appian RPA console. |
You can also create robotic process variables as you record actions with the task recorder.
To edit a robotic process variable:
To delete a robotic process variable:
Robotic processes follow a workflow, or a sequence of tasks. The workflow is the guide that leads the robotic process's operation, determining its starting point and driving it through a series of tasks and actions.
For more information, see Robotic Process Workflow.
The information in this section is also shown as a summary on the manual execution screen.
To configure general information settings:
Configure the following fields:
Fields | Description |
---|---|
Robotic process | Technical identifier assigned to the robot. This value is defined when creating the robot, assigned by the developer, and cannot be changed. This name will be used for creating folders both on the server and with the client, so therefore this is usually a technical name. |
Name | Functional name for the robot, which will be displayed on every window and will be the name by which the user will identify the robot. |
Spoken name | Name used when referencing the robot through voice commands. |
Work items | Name used to reference the items to be processed by the robot, such as bills, certificates, employees, and customers. Although not required, this name makes it easier for you to understand the statistics generated by the robotic process. The robotic process acts on an item. The type of item depends on the tasks the robot must accomplish. Typically, an item is associated with an element within a set of elements with similar characteristics. Some examples of an item could be a candidate who has sent his résumé, and whose name and contact information must be processed; the employee, for a robot that makes the payments of salaries; or a product, for a robot that checks the stock in a store's warehouse; or even a citizen for a robot that must gather data from a census registry. In short, the item identification will depend on the business process or the task to be performed. |
Priority | Execution preference of the robot with respect to the others waiting for resource availability. In the event of a tied priority, the first robotic process to be executed will be the one that was launched first. Priority values include: ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Default color | Color assigned to the robot by default to be shown in the schedule page, where you can see finished executions. |
Description | Main characteristics of the process. This appears on the Execution page when someone launches the robotic process. |
Integrated applications | Systems or applications taking part in the process. |
Expected input | Description of the input that will be used by the robot. This input is set up on the Robotic process variables area of this screen. |
Expected output | Description of the output that the robot will produce as a result of the execution. |
Disable new executions | By enabling this checkbox, the robot is disabled, preventing any scheduled execution. |
Test executions | By enabling this checkbox, all robot executions are marked as test executions, unless it is changed when launching the execution. |
Trace level | Refers to the minimum trace log level to be written into the robot execution log. |
Simultaneous executions (enqueued and running) | Maximum number of robot executions that can happen at the same time, both in status executing or queued. |
Allow executions only at these days/hours | By enabling this checkbox, a scheduler is shown to set up the days and hours when the robot can run. Outside these days/hours, the robot will not run, and if you try to run them, the system will initiate an event to notify such a circumstance. To schedule the executions, specify a time range in Days (select a day of the week or a specific day in the month) or Hours (select any or all hours of the day from 00-23). |
Every robotic process execution creates metadata or artifacts to help you evaluate how it performed. Over time, this data accumulates and can consume disk space to the point of negatively impacting performance. To keep your environment performing its best, you can configure when to delete this information. If you need certain information for auditing purposes, we recommend maintaining an Appian database table with the information you might need, such as the item processed, status of the process, and duration.
Permissions determine which users can view and control the robotic process, as well as which resources can execute the robotic process.
By default, a robot inherits the permissions of the user that created it. Learn more about permissions.
In the Advanced Configuration tab of the robotic process configuration page, you can configure the following settings:
In this section, you can choose how this robotic process behaves when executions are launched consecutively from an Appian process model. Options include:
If the robotic process doesn't require a resource to be reset before the next execution occurs, you can choose Skip setup and clean up for consecutive executions. This option speeds up each execution, and the compounded time savings can make the overall set of consecutive executions much faster.
Learn more about the Setup and Clean Up sections.
In some scenarios, setup and clean up sections are still run even if you choose to skip them for consecutive executions. These sections run when the:
Certain components of the robotic process configuration may behave differently when setup and clean up are skipped:
If you choose to skip setup and clean up for consecutive executions, be sure to design the robotic process workflow in the main section so it executes reliably in this manner. For example, if the robotic process is meant to submit a form multiple times with different data, be sure to add an action toward the end of the workflow for the robotic process to navigate back to the starting form. This way, each consecutive execution occurs smoothly and predictably.
You can define environment variables, which are sent to the robot as "key-value" pairs. The difference is that they are sent in all the executions but they are not requested in each execution. To modify them, it is necessary to modify robot settings. This facilitates having different configurations in different robot environments (for example, development and production).
To add an environment variable:
Configure the following fields:
Field | Description |
---|---|
Name | The name that serves as the key in the key-value pair. |
Value | The value for the environment variable. |
To edit an environment variable:
To delete an environment variable:
Sub-results are used to categorize the items results, making it possible to differentiate items already classified as OK or WARNING. The colors and statuses appear in the results column on the list of executions.
This items categorization is shown in the following table:
Icon | Color name |
---|---|
![]() |
CHOCOLATE |
![]() |
CORAL |
![]() |
CYAN |
![]() |
DARK_GRAY |
![]() |
INDIGO |
![]() |
LIGHT_GRAY |
![]() |
LIME |
![]() |
MAGENTA |
![]() |
OLIVE |
![]() |
RED |
For example, for a specific WARNING, you could assign a sub-result color to indicate different causes such as technical problems (sub-result CORAL) or data problems (sub-result CYAN).
Support files help you avoid having to add files in a robot's code, so the code is leaner and deploys much faster. Working this way also allows you to change the files' content (neither adding nor removing them) without affecting the robot's deployment.
In the Support files area of the configuration, you can upload support files to be either used by this robotic process only or shared globally among your robotic processes.
If you upload a ZIP containing an internal folder structure of support files and enable the Unzip on server option, Appian automatically creates the corresponding folder structure on the server. If you don't immediately see the unzipped contents of the file, but instead see the name of the ZIP file in the Root tree, refresh your browser.
To support methods in the Browser low-code module, the browser driver files must be stored in a specifically named folder in the Root tree. You must manually add this folder, and then unzip the driver files into that folder. For more information, see Using the Browser Module.
To manage support files to be used by this robotic process only, use the following icons within the Support files area of the workflow:
Icon | Description |
---|---|
![]() |
Preview the image support files. |
![]() |
Upload a new file to the server. |
![]() |
Download the file or folder from the server. When downloading a folder, Appian RPA creates a ZIP file for the folder and its contents. |
![]() |
Rename a file/folder on the server. |
![]() |
Create a new folder on the server. |
![]() |
Delete a file or folder on the server. |
In addition, by dragging and dropping any folder or file, you can move the folder or file across different locations in the folder structure on the server.
When you upload a ZIP file, you can specify if you want it to unzip on the server, thus creating the corresponding folder structure it contains upon upload completion.
If you want to share files between different robots, you can access the global support files. To do so, click on the Support files icon located in the Support files toolbar.
Essentially, this window is the same as the one displayed on the namesake area in robot setup, and hence their behavior is very similar regarding the uploading, downloading, moving, and renaming operations for files and folders.
From a visual point of view, the difference lies in how you define which robots can access which files.
For administrators, this structure contains support files for all robotic processes in your Appian RPA environment. For developers, this structure contains support files for robotic processes for which you have permissions. Files and folders display in alphabetic order. The folders are sorted first and then the files.
As you can see, there is a folder with files. To give a robot access to the global support files, it should have a permission with the same name as the folder it is trying to access. This folder will contain the folder structure and files the robot can use.
The table below shows the robots, their permissions, and the folders and files they can access, according to the previous picture:
Permission | Folder | Access | Robot |
---|---|---|---|
app07 | shared-folder-1 | shared-folder-1 | nodes.png |
app08 | shared-folder-1 | shared-folder-1 | nodes.png |
shared-folder-2 | shared-folder-2 | shared-subfolder-2.1 (D) robot-file-2-1.png robot-file-2.png robot-file-1.png | |
app12 | shared-subfolder-2-1 | shared-subfolder-2.1 | robot-file-2.1.png robot-file-2.png |
Robots app07 and app12 can access the content of only one folder of the global support files since each of them has the proper permission.
Remember that you cannot use the period character .
in a permission tag, but you can use the hyphen character -
. So to access the folder
shared-subfolder-2.1 you should specify the permission shared-subfolder-2-1.
Robot app08, on the other hand, can access both folders. One of them contains only one file, whereas the other one contains one file (robot-file-1.png) and one folder (shared-subfolder-2.1). The latter contains, in turn, two files.
The following shows an example of how we could obtain the path to access a file uploaded in this section.
1
2
3
4
5
Path path = Paths.get(
server.getCurrentDir(),
"folder",
FILE_NAME).
toRealPath(LinkOption.NOFOLLOW_LINKS);
In the previous code snippet, we assume that we have a folder called "folder", and a file whose name is defined in the constant FILE_NAME.
This section is relevant to custom code development only. If you're using low-code modules, you can ignore this section.
At the end of the page, you can see the definition of the repository where the project has been automatically deployed. To make this link work properly, it is necessary to have previously deployed the robot binaries in the defined Maven repository. This is done using the following instruction:
mvn clean deploy
In this section, you can find the technical information contained in the robot setup:
It is possible to select the robot's main class if the Maven artifact's information has been setup properly. To do so, click on the Select main class
icon and select the main class from the list of all classes available in the Maven artifact.
In case some of the fields of the Maven coordinates associated with the artifact are not correct, an error message will show up as a warning. If no classes are shown, check that the artifacts successfully deployed to Maven, as well as the Maven configuration is correct.
Use the Check dependencies button to validate that the configuration of the robot is correct in terms of dependencies and the versions of these dependencies. A window appears that shows the artifacts that have a different
version in the robot and in the agent.
Required role: Developer or Administrator
In the toolbar, after the breadcrumb indicating the robot's name, you can see a set of icons with an arrow and a clock. Through this arrow, we can go back to previously recorded versions of the configuration, thus recovering old configurations that have been overwritten for whatever reason.
You can use the arrows to navigate back and forth through the configuration versions that have been saved previously.
Required role: Developer or Administrator
To copy a robotic process configuration:
Click the Duplicate robotic process icon in the toolbar. The Confirm copy window displays.
Required role: Developer or Administrator
You can download a ZIP file containing the robot configuration, so it is possible to import it to the same or other consoles.
To export the configuration:
Required role: Developer or Administrator
To remove a robotic process configuration: