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.

Toolbar

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

Change history

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.

General information

The main information in this section is also shown as a summary on the manual execution screen.

• 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: Word that defines or identifies the items to be processed by the robot, such as bills, certificates, employees, customers, etc. Although not required, it is advised to define this section for each robot, to make it easier to understand the statistics by the user.
• 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.
  • Highest.
  • Very high.
  • High.
  • Normal (default).
  • Low.
  • Very low.
  • Lowest.
• 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 section 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 (queued 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:
  • Days: you can choose on a day-to-day basis or select the days of the month.
  • Hours: you can select any or all hours of the day (00-23).
• Remove old artifacts (days): Number of days after which artifacts generated by executions are removed in order to free disk space. The list of artifacts affected by this option are:
  • Inbound (Parameterized robotic process variables)
  • Images
  • Files of results
  • Video

Items

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.

Robotic process variables

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.

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.

Parameterized variables

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.

Workflow

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.

Actions

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:

• Initial: The first action, the starting point of the workflow.
• Generic: An action by which the robot must perform some specific task before continuing with the next action.
• Conditional: An action that represents a fork in the workflow. Based on the input, the workflow could proceed in different ways.
• Final: The ending point of the workflow.

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:

1. With the initial element selected, click on any of the connector points.
2. Drag and drop on the destination element.
3. The editor will assist you in "pasting" the arrow to the destination action.

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:

1. Sections: if the workflow contains subsections, the way to indicate it in the main workflow is by choosing this section.
2. Methods: Methods written in the robotic process's source code, specifically in the class annotated with \@Robot.
3. Modules: A list of low-code methods. Modules contain methods that are not developed by an Appian RPA developer in the source code. They can be seen as default actions on elements a robotic process interacts with. Each of the methods explain what they do and provide the necessary fields for each method.
4. Libraries: contains custom methods written by Appian RPA developers that are shared across multiple robots.

Methods

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.

Modules

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:

To associate a method from a low-code module with an action:

1. In the workflow editor, add an empty action. You can select a generic or conditional action.
2. Click the list icon .
3. From the Module tree, open a low-code module and select a method. The right-hand pane displays the method and any available parameters that can be added or values that can be stored.

   If you selected a conditional action, only low-code modules that return boolean or string values appear.

4. If your selected method includes parameters, you can:
   • Enter a static value
   • Select a robotic process variable from a picker
   • Use the Expression editor to write an Appian expression. You can reference a robotic process variable in the Expression editor using pv! and concatenate variables as needed.
5. If you select a method that returns a value, choose to either store or append the value to a robotic process variable using the Operator dropdown.
6. In the Save Into field, enter the name of a variable. If your process variable is type CDT, you can specify which field of a CDT to store the value into using dot notation.
7. To add more than one method to an action, click the Add Action icon .
8. Click OK.

Scripts execution

From the workflow, you can call specific methods of the API to execute arbitrary code. Currently, only Groovy scripts are supported.

1. From the Modules tree, select Robot > Execute code or Execute code with result.
2. In the Language dropdown, only the option GROOVY appears.
3. In the Code field, enter the code to execute.

Sections

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.

Clean up section

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.

Create a section manually

1. Go to a robotic process configuration.
2. In the workflow section, click the Create section icon .
3. Give the section a name and click OK.
4. Design the section's workflow. You'll need to add at least two actions: initial (start) and final (end).
5. Click Save to save the 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.

Create a workflow section using Selenium

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.

You can add Selenium IDE as an extension to your preferred browser for quick access. To get started, download Selenium IDE.

Best practices

Before you record a workflow, keep these tips in mind:

• Determine the key steps in the process. One benefit of robotic process automation is repeatedly handling routine tasks. Each step in the process impacts how long the robotic process takes to complete the execution. Before you record your actions in Selenium, think through your movements and interactions on the screen so they are as efficient as possible. An efficient Selenium script makes your robotic process efficient as well.
• Be mindful of limitations. Appian RPA accepts Selenium files (.side) with up to 10 tests and 50 commands per test. Plan your recordings with these limitations in mind.

Supported actions

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.

Capturing a workflow using Selenium

1. Launch the Selenium IDE.
2. If this is your first test, select Record new test in a new project.
3. Type a Project Name.
4. Enter a Base URL. This is where your test will start recording.
5. Click Start recording.
6. A new browser window opens, navigates to the base URL you specified, and begins recording. During recording, you can see the actions captured in the Selenium IDE window.
7. When you're finished recording, save the project. You're prompted to save it to your computer as a .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.

Importing a Selenium script to Appian RPA

Import the Selenium file to automatically create actions in a robotic process workflow in Appian RPA.

1. Open a robotic process configuration in the Appian RPA Console.
2. In the Workflow section, click Import section from Selenium file.
3. Click Upload to browse for the .side file, or drag and drop it in the Import section dialog.
   • Remember the import tool only accepts .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.
4. Click Continue to proceed to Configure section(s). Here, you'll see any commands that aren't supported and won't be imported. You can also rename the section.
5. Click Import.
6. Appian RPA parses the Selenium file to actions in a new workflow section. Open each of the actions to confirm.
7. The section's name matches your recording name and is saved automatically. You can change the section name.
8. Configure additional options in the workflow's actions, such as storing outputs to variables. You may also want to configure wait, failure, and screenshot options.
9. Optionally, add more actions to the workflow. You'll need to manually add actions for steps that weren't imported or easily recorded, such as conditional actions.
10. Click Save when you're finished and ready to use the section in the main workflow.

Use the new section in your workflow

Back in the main workflow, you can add the section in an action node:

1. In the workflow, click Add generic action.
2. Open the new action. In the Sections menu, select the section you just created.
3. Click OK.

Import a workflow

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:

Saving a workflow

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:

1. There are, at least, one initial action and one final action.
2. All actions have associated text.
3. All actions are interconnected through at least one transition.
4. All actions have one and only one output transition, except conditional actions.
5. All actions have one associated method.
6. All conditional action's outputs have one associated literal. These literals must match each possible value of the return instructions present in the code of the method used. You can leave one output with no literal definition, assuming this case is the empty string option (""). When the associated conditional method returns a boolean, the literal for the connections must be either "true" or "false".
7. Conditional actions' outputs are not repeated.

Permissions

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.

Environment Variables

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 description

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:

• CHOCOLATE ( ).
• CORAL ( ).
• CYAN ( ).
• DARK_GRAY ( ).
• INDIGO ( ).
• LIGHT_GRAY ( ).
• LIME ( ).
• MAGENTA ( ).
• OLIVE ( ).
• RED ( ).

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).

Support files

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.

Access support files in code

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.

Global support files

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:

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.

Technical information

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:

• Technology: Technology in which the robot has been built: Java, AutoHotkey or Autoit. If you choose the latter, the form will only have fields for Executable and Version.
• Repository: Maven repository where the robot code is located.
• Group: Identifier for the group of the robot's Maven artifact.
• Robotic process: Identifier for the robot's Maven artifact.
• Version: Version of the robot's Maven artifact.
• URL: Complete URL to the robot's Maven artifact, only necessary if previous fields are not specified.
• Main class: The main class to be executed, that is, the input class for the robot.

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.