This page dives into how to add or modify a robotic process's configuration. The configuration contains most information regarding the process, including the workflow. A robotic process configuration also includes technical information such as the repository and technology that power the robotic process.
When you create a robotic process, you'll specify its configuration. You can edit a robotic process configuration at any time.
For any changes you make on this page, be sure to click the Save button at the bottom of the page.
In the upper right-hand corner of the robot configuration page, we can find different icons for the actions to perform upon the robot.
Icon | Description |
---|---|
![]() |
Send robotic process to another console. When clicking on this icon, a pop-up window will show up where we must introduce the information about the destination console URL, as well as the credentials for a valid user in it. |
![]() |
Clone the robotic process. The new robot will keep the characteristics of the original, and then you will be able to edit them. This way, you save time in comparison to creating a robot from scratch. |
![]() |
Copy the selected robot's settings to another robot |
![]() |
Download robot configuration. Download a ZIP file containing the robot configuration, so it is possible to import it to the same or other consoles. |
![]() |
Execute the robotic process |
![]() |
Delete the robotic process |
At the top of the configuration page, after the bread crumb indicating the robot's name, we 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.
Through these arrows we can navigate back and forth through the configuration versions that have been saved previously.
The main information in this section is also shown as a summary on the manual execution screen.
The Appian RPA Robots operate on an item, which is the element to be processed. As mentioned above, 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.
This section allows you to create process variables that 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 low-code modules to display values or to store a method'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.
To create a new robotic process variable, navigate to the Robotic Process variables section and click Add variable. A new row appears where you can configure the variable using the following fields:
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.
Field | Description |
---|---|
Name | The name of the robotic process variable. Only letters, numbers, and underscores are accepted. |
Description | Descriptive text about the variable. |
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). |
Initial value | The default value of a robotic process variable. Note that you cannot provide an initial value if you select the Mutiple? 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. |
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. |
Multiple? | 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. |
To reference process variables in your workflow, use the low-code modules. To access robotic process variables from your source code, use the getWorkflowVariables() method in the server function. Note that you cannot update a variable's CDT value from the source code. To update a field in a CDT, you must use a low-code module.
When you create a process variable and mark it as a parameter, 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. If you mark the variable as required, the robotic process will not run unless a value is provided to the variable at the time of execution.
In previous versions of Appian RPA, parameterized variables were called instructions. However, instructions were limited to only a few data types and could not be updated throughout the course of the robotic process. With parameterized variables, you have the flexibility to add input values of any primitive data type, CDT, or legacy instruction type, like File, Password, or Dropdown (formerly called Combo), and you can update the value of the parameter in the process. When you upgrade to the latest version of Appian RPA, any instructions within an existing robotic process will be migrated to robotic process variables.
To pass values to your parameterized variables, use the Execute Robotic Process smart service. Using this smart service, you can configure node inputs to pass one or multiple values at the start of your process. For manual executions from the Appian RPA Console, you can supply a value to the input field on the Execution options page. However, executions from the console can only pass one value to a parameterized variable, even if your parameterized variable is set to support multiple values.
For situations when you want to access and process parameterized variables from your source code, use the getWorkflowParameters() method from the instance server to return all workflow variables marked as parameters.
To learn how process variables allow data to flow between your robotic process and other design objects, see Using robotic process variables.
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.
The workflow of an Appian RPA robotic process can be compared to a sequence of tasks performed by a human. Visually, the workflow makes it easy to monitor a robotic process's operation from the console. It enables a global view of all execution phases and allows you to analyze what action the robot is on, when it began, its duration, and its result. The console draws the workflow as the corresponding robotic process operates.
For example, let's suppose one person should perform a task that involves gathering names and contact information from people who have sent their résumés through the company's website. This data then needs to be documented and saved on Notepad, using one line for each name.
Assuming that the data source will always contain at least one résumé, the workflow could look like:
The workflow mimics how a human would go through the process: First the person would open Notepad, read a résumé, and then write the candidate's name and contact information in Notepad. If there are more résumés, the cycle should go back and the person should read the next résumé. If there are no résumés left, then the Notepad document should be saved and closed, reaching the end of the whole process.
Defining the workflow is the first and one of the most important steps for building Appian RPA robotic processes. A good design will make the robot easier to develop.
Looking to speed up workflow design? Create workflow sections using Selenium IDE scripts.
Within your workflow, you must associate actions with the robotic process's code so that each action corresponds to one method in the class that implements it. These actions can be:
When you are developing a robotic process, typically, it's in the first action where variables are initialized and everything needed for the robotic process to accomplish its task is prepared. Then it will go through each action in the workflow, until it reaches the last one, and the execution ends. The difference between an initial action and a final action lies in their transitions. An initial action has no input transition and one output transition. A final action has at least one input transition and no output transition.
Actions connect through arrows, representing the workflow's transitions.
There are a number of actions you can create in a workflow. You'll find the create action buttons along side other options in the Workflow section:
Icon | Description |
---|---|
![]() |
Add an informative note to the workflow. It does not affect to the workflow itself. |
![]() |
View and associate Appian RPA libraries to the workflow. |
![]() |
Create a start/end action. |
![]() |
Add a generic action (task). |
![]() |
Add a conditional action (decision). |
![]() |
Download a workflow image in SVG format. |
![]() |
Save the changes made on the workflow. |
![]() |
Undo the last action made on the workflow. |
![]() |
Select all actions of the workflow and their relations. |
![]() |
Export the selected actions and relations of the workflow. |
![]() |
Import actions and relations into the workflow. |
![]() |
Import from file. |
![]() |
Reset the workflow's size. |
![]() |
Set the workflow's zoom level at 100%. |
![]() |
Zoom out of the workflow. |
![]() |
Zoom in on the workflow. |
![]() |
Aligns to the left all the selected elements in the workflow. |
![]() |
Centers horizontally all the selected elements in the workflow. |
![]() |
Aligns to the right all the selected elements in the workflow. |
![]() |
Aligns to the top all the selected elements in the workflow. |
![]() |
Centers vertically all the selected elements in the workflow. |
![]() |
Aligns to the bottom all the selected elements in the workflow. |
Double click an action to name it. Click and drag on the double arrow icon to resize the action.
For example, a modified workflow could look like the following:
It is possible to work on two or more actions at the same time, for example when cutting, pasting, or deleting.
To select more than one action simultaneously, hold the Ctrl key (Windows) or Command key (Mac) and click each action to select. To select all actions, click the Select all icon .
You can move, delete, or copy and paste the selected actions. You can also export them, which will make the selected actions serialized, producing a string that can be stored in a file or shared by any means that allows plain text communications. You can use this string to import multiple actions at a later time. A text field will ask you to enter the values serialized by the export option.
When you import actions, their initial position in the editor is kept. Therefore, some actions could overlap with others, even hiding those previously in the editor. In these cases, you should select them and move them apart to check if the import was successful.
To transition between the actions, add the arrows to make connections:
To save the changes made on the workflow, click on the Save icon
. You can undo the changes at any time by clicking on the Undo icon
.
There are four groups that can be assigned to the different actions in the workflow:
To associate a method with an action, click on
the list icon and pick the corresponding method from the drop-down list.
Then on the detail window, you will see a tree view of the methods available for the robot and the associated libraries that can be assigned to the action. On the right-hand side, you can view the code of the selected method before clicking on the accept button.
If the method does not yet exist, you can add it manually by writing its name. Before running the robot, you should deploy the corresponding code including the new method. You can also set "No action", assigned by default, if you don't know what method will be associated with the robot yet. Actions with such value will be ignored during robot execution.
Actions with the value "No action" selected will be displayed using a specific format on a grey background.
You can add multiple methods in one action. Click the action icon to add more. Each method to select can be can be in sections Methods, Modules, or Libraries. Methods are executed in the order they appear for that action.
In the console, low-code modules contain methods that you can easily configure without needing to go into your source code. These low-code modules provide a user interface where you can add values to parameters and store returning values in robotic process variables.
In the workflow editor, the following low-code modules are available:
Low-Code Module | Description |
---|---|
Appian Services | Provides methods to start an instance of a process model or evaluate an Appian expression. |
Browser | Provides methods to interact with a supported web browser: Chrome, Firefox, or Internet Explorer. |
Execution | Provides methods to launch a robotic process or check if a robotic process is able to run. |
Image Recognition | Provides computer vision methods to locate and act upon an image. |
Items | Provides methods to manage item processing context and communicate with the server. |
Keyboard | Provides methods to type or interact with the keyboard. |
MultiOS | Provides methods to interact with any operating system. The methods here allow development to be independent of specific operating systems. |
Robot | Provides basic robotic process methods such as Pause, Execute, or Default pause. |
Server | Provides methods related to logging and the clean up process. |
Smart delay | Provides methods related to robotic process wait time. Since robotic processes move faster than humans, you need to incorporate wait time in your process. |
Window | Provides methods to interact with a Windows operating system. The methods here are operating system specific. |
To associate a method from a low-code module with an action:
If you selected a conditional action, only low-code modules that return boolean or string values appear.
pv!
and concatenate variables as needed.From the workflow, you can call specific methods of the API to execute arbitrary code. Currently, only Groovy scripts are supported.
Sections allow you to break down complex actions into a set of actions in their own workflow. You can then use sections as actions in the main workflow. Sections operate in a way that's similar to sub-processes in an Appian process model, except they can only be used within the robotic process where they're created. Sections help keep the main workflow organized and make it easier to understand what's happening at a high level.
Sections can be helpful when the robotic process is set up to repeat the same actions multiple times. For example, rather than building a loop with four actions in the workflow, you can instead create a section for those four actions. Then, you can add the section as one action in the main workflow.
By default, every workflow has at least one main section. You can define multiple additional sections inside the same workflow. There's no limit to the number of additional sections that can be incorporated into the workflow. You can create a section manually using the instruction below, or create a section automatically by importing a Selenium file.
Appian RPA provides a Clean up section by default. Whether the robotic process ended successfully or not, the end of an execution is a good moment to close the applications that the robotic process has opened or send the files generated during execution to the server. It's important to reset the resource to its previous conditions so subsequent robotic processes can execute successfully. Without consistent starting conditions, other robotic processes may not be able to start or complete.
In the clean up section, you can configure the steps the robotic process should take when it's complete, such as closing programs it opened. Remember that the steps you configure in this section only apply to the robotic process you're currently configuring.
You don't need to add the clean up section to your main workflow. The robotic process will always execute the clean up actions. If you use Java methods in addition to the clean up section in the console, the Java methods execute after the low-code section.
To use the section in the main workflow, associate it with an action. The list of available sections appears in the Actions menu. When you associate a section to an action, the icon will change its appearance to dark blue () in the workflow.
Click Remove section in the workflow to permanently delete it.
Robotic processes are designed to interact with interfaces in the same way as human beings. To emulate a human being's actions on the screen, a developer needs to consider every step in the process: every click, every pause, and every text input. It can be difficult to trace every single step you take when interacting with a website or program. Selenium IDE is a browser automation tool you can use to build a script that captures these actions. You can import the Selenium script to Appian RPA to automatically create workflow actions to match the ones you recorded.
Appian doesn't support the Selenium tool itself, only the ability to import Selenium files to auto-generate a section. This section describes the steps and best practices to create a file to import in Appian RPA. For help and support, consult the Selenium documentation.
You can add Selenium IDE as an extension to your preferred browser for quick access. To get started, download Selenium IDE.
Before you record a workflow, keep these tips in mind:
.side
) with up to 10 tests and 50 commands per test. Plan your recordings with these limitations in mind.Use the following table to see how Selenium actions will be configured as Appian RPA actions. If a Selenium action isn't listed, it's ignored during import. Learn more about Selenium Commands and Browser module methods.
Selenium Action | Browser Action |
---|---|
Add selection | Interact with element |
Assert checked | Wait for attribute |
Assert editable | Wait for attribute |
Assert not checked | Wait for attribute |
Assert not editable | Wait for attribute |
Assert not selected value | Get attribute |
Assert not text | Get attribute |
Assert selected label | Get attribute |
Assert selected value | Get attribute |
Assert text | Wait for attribute |
Assert value | Wait for attribute |
Check | Interact with element |
Click | Interact with element |
Double click | Interact with element |
Edit content | Interact with element |
Remove selection | Interact with element |
Select frame | Select frame |
Selection | Interact with element |
Store attribute | Get attribute |
Store text | Get attribute |
Store value | Get attribute |
Type | Interact with element |
Uncheck | Interact with element |
Verify checked | Wait for attribute |
Verify editable | Wait for attribute |
Verify not checked | Wait for attribute |
Verify not editable | Wait for attribute |
Verify not selected value | Get attribute |
Verify not text | Get attribute |
Verify selected label | Get attribute |
Verify selected value | Get attribute |
Verify text | Wait for attribute |
Verify value | Wait for attribute |
.side
file.Selenium lets you modify recorded commands and insert additional commands for actions that aren't easily captured during your recording. If you insert or modify commands, refer to the Supported Actions table to make sure the actions will be imported properly.
Before you import the workflow to Appian RPA, it's a good idea to use Selenium's playback tool to confirm the script acts as you expect. Make changes to the Selenium script before importing to Appian RPA to save time debugging.
Import the Selenium file to automatically create actions in a robotic process workflow in Appian RPA.
.side
file, or drag and drop it in the Import section dialog.
.side
files with a maximum of 10 tests and 50 commands per test. Appian RPA alerts you to these errors if the file exceeds the limits, is the incorrect type, or contains invalid content.Back in the main workflow, you can add the section in an action node:
You can also import a workflow from a BPMN file. Click the Import from file icon and browse for the BPMN file to import.
The console will process the file, reading the BPMN tags defined on it and map them to the appropriate workflow components:
Tag | Workflow component |
---|---|
bpmn:process | Section |
bpmn:subProcess | Section |
bpmn:startEvent | Init |
bpmn:endEvent | End |
bpmn:task | Action |
bpmn:globalTask | Action |
bpmn:intermediateThrowEvent | Action |
bpmn:intermediateCatchEvent | Action |
bpmn:exclusiveGateway | Conditional Action |
bpmn:sequenceFlow | Arrow |
bpmn:dataObject | Note |
bpmn:dataStore | Note |
bpmn:dataObjectReference | Note |
bpmn:dataStoreReference | Note |
bpmn:message | Note |
bpmn:collaboration | Note |
bpmn:textAnnotation | Note |
bpmn:text | Note |
When a workflow is saved, some checks are performed. These checks may send a warning message, but the workflow is still saved though, it may not be correct. Appian RPA checks that:
This is the area where you will assign permissions to the robotic process.
Permissions will determine what users will be able to view and control the process. The permissions you assign to the robotic process should also match the resource on which it will be executed. If we don't assign the proper permission, the Appian RPA Platform won't be able to find any appropriate resource to execute the robotic process and users won't be able to see it either.
By default a robot inherits the permissions of the user that created it. Learn more about permissions.
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 (development, production, etc.)
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 list:
An example could be, for a specific WARNING, to know its different causes, as technical problems (sub-result CORAL) or data problems (sub-result CYAN).
In this section, you can find the folder structure containing the technical and configuration files that a robot needs for proper operation. Support files help you avoid having to add files in the robot's code as resources, so the code is leaner and helping deploy it much faster. Working this way also allows you to change the files' content (neither adding nor removing them) without affecting the robot's deployment.
Here you can upload new files to the server, even ZIP files that will create the folder structure they contain if you previously enable unzipping through the corresponding checkbox.
Files and folders will be displayed in alphabetic order. The folders will be sorted first and then the files.
You can execute the following actions in the resources in tree view that show the folder structure:
Icon | Description |
---|---|
![]() |
By pressing on this icon, we can preview the image support files. |
![]() |
This icon allows you to upload a new file to the server. |
![]() |
This icon allows you to download the file or folder from the server. When downloading a folder, a ZIP file will be created with the folder and its whole content. |
![]() |
This icon allows you to rename a file/folder on the server. |
![]() |
This icon allows you to create a new folder on the server. |
![]() |
This icon allows you to delete a file or folder on the server. |
In addition, by dragging and dropping any folder or file, you can move them 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.
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.
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 on the Robots window.
Essentially, this window is the same as the one displayed on the namesake section 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.
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.
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.
On This Page