Appian RPA Design & Development Best Practices

RPA Development Best Practices enhance application quality and reduce troubleshooting time. These best practices should be followed, in addition to Appian Documentation. Ensuring that best practices are followed from the beginning maximizes the chances of the success of a project. This is a living document to be updated as needed.

Development Tools

The most powerful tools to develop and test the robotic process are the Appian Task Recorder and the debugger

Appian Task Recorder

If we need to automate Web Applications or Windows applications, we must use the Appian Task Recorder to capture the interactions.

When you use the Recorder for browser automation, we recommend:

• Verify that the selector chosen only finds one element.

• Avoid using the keyboard except for typing text on input fields. For example, click a button with the mouse instead of pressing enter.

When you use the Recorder for Windows Automation, we recommend:

• Open the application from the recorder. Once the recording is saved, you can move this step to the setup section.

                                    

• Save the steps to close the application. Once the automation is done, you can move these steps to the Clean up section.

• Avoid using keyboard shortcuts in the recorder.
• If the task recorder list flow results in unwanted/extra steps, they can be removed in the task recorder before saving to the RPA process.

Debugger

Debugging in the execution preview is the best tool to solve problems in a specific action.

• When an execution breaks due to an error, using the debugger can help in capturing a better diagnosis in the execution log. Specifically, breakpoints can be specified just before the error-causing step to provide more valuable information, since the process will not move forward to the next steps.
• For browser automations, a breakpoint can be inserted just before the action designed to select or retrieve an element.

• After the break, by going into the resource manually, right clicking the element in Chrome and clicking “Inspect” can be used to copy and verify the XPATH.

Low Code Modules

Browser

• Always select “Scroll to Element before interaction” when configuring the browser method “Interact with Element”. With this, the bot will always scroll to the element. This improves visibility for recordings, testing, and troubleshooting.
• Always activate a window before interacting with it. When switching to a browser window, use “Switch to Tab or Browser” to bring the window to the front.
• What is the best selector to interact with elements? Appian RPA provide multiple ways to locate a Web Element on the page (id, name, xpath, css ..). Task Recorder always prioritises the Id over the other selectors, because this value will be unique on the web page. But sometimes web pages have dynamic Id's and the recorder cannot identify this during a recording. In that cases, you should test with the Task Recorder what is the most accurate selector.

Execution

• Each “Log” low-code action should include enough information to know the result of the actions; or in case of an error, the reason for the execution failure. Consider including the values of the  input/output variables, but never include confidential information in the log file.
• Determine the right trace level for each log trace defined in the List Flow. When the robotic process is executed in production environments, it should use the INFO trace level. This allows to increase the execution speed of the robot by reducing the detail of the trace to be displayed. For doing this in General Configuration tab, select the level of the trace:

• The Pause action should not be used in robotic processes deployed in production. We recommend rather:
  • Try to use Smart Delays through the Get Attribute and Interact With Element low code actions. A robot must adapt its speed to the applications it is using. The waiting time depends on factors such as the performance of the machine on which the robot is running (processor, RAM, virtual environment), and it may be different in each execution. The low code actions Get Attribute and Interact With Element in the Browser and Windows Automation modules include the parameter Wait time. This parameter will be the max waiting time to interact with the element defined in the Low Code Action.

• If you still need to have a fixed pause, set a “Wait before executing next action” on the low-code action where you would like the bot to pause

File System

• Avoid creating or manipulating files and/or folders in the resource manually. If the robot needs to access a folder or file, please use the File System action to validate, create and delete those files or folders during its execution.
• It is recommended to delete all execution-related files at the end of each execution using the “Delete a file or a folder” action (see Clean Up in the Setup Section), unless files are absolutely necessary to remain on the resource.

Image Recognition

• Image recognition should be used only when other modules like Browser or Windows Automation can’t be used, for example, in Citrix environments. This is because image matching only works when the image is fully visible on screen.
• When capturing the images to be searched for, make sure there is only one matching image on the screen.
• Try to capture the most representative pixels of the image and, if possible, ensure that they are small images. Applying these two best practices, the Image recognition’s behavior can be significantly reinforced.
• As with Locate Image, ensure that the resource's screen resolution remains equals when capturing the coordinates to use.

Items

• Items should be used when an RPA process requires more specific traceability and results classification within the execution log
• Use the “Set number of items” action at the beginning to set the total number of work items to be processed in a given execution
• Use the “Set item result” action to log a result as either “OK” or “WARN”, depending on where the execution flow ends. These can be used along with sub-results (setup in the “Advanced Configuration tab”) to provide more information in the summary of the execution of the processed item
• Note that configuring this does not mean that the process already has sub-results configured, this configuration is just a way of labeling each of the sub-results that were previously used in the workflow for a better understanding of their meaning

Keyboard

• Keyboard shortcuts should only be used if efficiency is significantly increased. It is not recommended to use these for browser automations, especially using the recorder.
• For writing text to the field of a screen, use the “Update Value” interaction of the “Interact with Element” method, present in the Browser and Windows automation modules, when possible.
• If the size of the text to type is large, use the “Set Clipboard Value” and “Enter Keyboard Shortcut” of Ctrl+V, instead of “Type Text”. This will save time since the full text will be pasted immediately rather than each character being typed out. Note that the appropriate textbox or text field will need to be selected first (with the click interaction instead of update value).

Mouse

• Mouse actions should generally be avoided in browser automations and windows automations without coordinates specified
  • Coordinates should only be utilised as a last resort, after image recognition
• For clicking on an element, it is recommended to use the “Interact with Element” method with a “Click” interaction.
• Using the “Click” action can only be used when the mouse is already positioned on where to click or exact coordinates are provided.

Operating System

• For closing all legacy and/or non-browser applications at the end of the execution, the “End Process” action should be configured for each application in the cleanup section

Windows Automation

• When switching to a desktop window, use “Set Search Context” to set the driver context.
• For opening windows applications, use “Open Application” in the setup section

List Flow

Application Security

• Credentials must be updated in the console each time they are changed in the target application.
• Permission Tags. Each parent robotic process (not used as a subprocess) should have its own permission tag with the same name as the robotic process. Each robotic process should contain the tag of the resources, credentials and libraries to use.
• Appian RPA has a default permission of “roleoperation”. In order to better control the access/execution of robots across different business units, user groups, etc., consider not using the “roleoperation” tag.
• Each robotic subprocess should have permission tags for each of its calling robotic processes. Lastly, each resource should have the permission tag of each robotic process that directly uses it, excluding subprocesses.

Clean Up in the Setup Section

• Generally, an RPA process must have a Close Browser / Close Application(s) action in the Clean up Section. 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
• If a robotic process unexpectedly fails to completely clean up the VM when going through its Cleanup section, it could cause problems processing on future executions. Therefore, in the Setup section, every application to be used by the robotic process should be closed by its process name.
  • Refer to the example below where we close Chrome in the Setup section

• If a robotic process saves documents to the VM (by either saving docs on the VM itself or via downloading docs to the VM from Appian), then the robotic process should be used in the Clean Up section group to delete all documents from the folder (if any exist). This will ensure that if any documents are lingering from previous executions for any unexpected reason, then those documents will not be accidentally used in the current or future processes.

Exception Handling

• Business Exceptions:
  • Before making the robot, we have to know which are the possible business exceptions that may appear.
  • We must implement conditional actions to catch each business exception known.
  • If we are working with items, It is recommended that these exceptions be marked as warnings (WARN) instead of as errors themselves.
  • Provide in the response all the information necessary so that users can complete or correct the deficient information and retry its processing.
  • See more details in the documentation.
• Unplanned Exceptions:
  • We have to take into account that the applications to be automated may not work at the time of execution.
  • We should develop the proper conditional low code actions to ensure that these applications are opened correctly. If not, we need to return a specific error type to take actions such as sending an email to those responsible for maintaining the applications. See more details in the documentation.
• Subprocess Exceptions:
  • If systemExceptionIds or businessExceptionIds are included in a subprocess, they must be mapped to output process variables in the main process if either of these values are affected. For instance, this paradigm would need to be followed for exceptions resulting from a child process for logging into a web application or SAP systems.

Executing Robotic Subprocesses

• Similar to Appian Process Model Design, it's important to break out sets of reusable RPA actions into their own processes. This way, the code can be used by multiple “parent” RPA processes, but only needs to be updated in one place.
• Reserved credential: Choose a reserved credential. This option is needed only when you're using the current process as a robotic subprocess. You can select a credential that was reserved and saved to a variable in the parent robotic process.

• If an RPA subprocess has business exception logic, it's important to map for example loginFiled both to and from the RPA subprocess. It’s also important to declare an output of the systemExceptionId from the subprocess if it writes to the systemExceptionId at any point in its workflow.

Naming Conventions

• Constants:
  • ABC_TXT_XPATH_OK_BUTTON
  • ABC_TXT_XPATH_USERNAME_FIELD
  • ABC_TXT_WINDOW_TITLE_HOMEPAGE
  • ABC_INT_DEFAULT_WAIT_TIME
  • ABC_TXT_LABEL_BOT_COMPLETED_SUCCESSFULLY
  • Constants should follow Appian naming conventions (all capitalised, words separated by underscores, beginning with application prefix)
  • Once the automation has been validated, use constants for all RPA selector values, text labels, and window titles. Changes to selectors will be made
• Expression Rules:
  • Expression rules should follow standard Appian naming conventions
  • If an expression rule results in a true/false value that changes the list flow, use the “Is Expression True” action. Otherwise, the “evaluate expression” action can be used to store the result of an expression in a process variable
• Actions:
  • Action naming should be renamed to include details regarding the activity being done by the robotic process. Some examples:

• Action Groups:
  • All action groups should be labeled with the overarching activity performed by the result of actions within the group
  • Action groups should be used when there are two or more low-code actions necessary to accomplish a single task
  • For example:

• Robotic Process Naming:
  • For example: ABC_queueWork, ABC_processWork
  • All robotic processes should begin with the appropriate Appian application prefix
  • No spaces in robotic process names & use camel casing after the prefix
  • If there is a general data framework used for the application, the “RDF” prefix (RPA data framework) can be used for those processes (e.g. RDF_openApplications)
• Robotic Subprocesses called within the RPA list flow should be labeled with the name of the RPA process accessed. For example:

• Images: When image recognition is used, the action label should include the name of the file being located for easy identification. For example:

Readability

• Ensuring good readability will also drastically reduce the amount of time you spend during troubleshooting and debugging, as well as during bots maintenance.
• As far as possible, use Action groups to help organize actions that work together to achieve a desired outcome.
• Use rules and constants instead of hard-coded values

Screenshots

• Send audit screenshots at key steps in the robotic processes. A usual robotic process use case is entering data into an application. It is a best practice to send a screenshot with the confirmation received from the application once the automation finished. The same as we recommend for log traces, never send screenshots with confidential information.
• Reduce the number of screenshots taken unless necessary for debugging. It is important to keep in mind that in production we have to send only the necessary audit images. Indeed, each image sent consumes execution time and disk space, we have to be careful not to overload the system.

Wait Times

• RPA action wait times should always be specified using process variables or constants. These should then be used throughout the process to handle all cases of loading elements or pop-ups.
• Using a constant:

• Using a process variable:

Appian Integration

Appian Services Low-Code Modules

• The Start Process action kicks off an asynchronous run of any Appian process model. It is preferred that RPA processes do not kick off Appian process models since the RPA process will continue to the next actions before the Appian process is complete.
• When an RPA process extracts documents from a system or website, the Upload Document can be used to place the retrieved file into an Appian folder.
• Similarly, download document should be used when an RPA process needs to retrieve a file from Appian and perform actions on it or move it to another system

Process Model

• A connected system and integration must be setup in the Appian designer before using the Execute Robotic Process smart service
• The number of retries can be setup directly in the smart service
• XOR nodes should be used whenever a process hits an error and a process model action is needed as a result (e.g. alerting a group via email that an RPA process has failed)
• The node outputs can be utilised to view the RPA process variables, which can be used alongside XORs to determine different flows for business exceptions.

Input / Output Data

• CDTs can be used within Appian Enterprise (AE) to manage customised input/output data between AE and Appian RPA.
• After creating a connected system for Appian RPA, an integration must be set up with the correct rule inputs to pass through to the RPA process

• After the CDT and integration is configured in Appian Enterprise, you can create a process variable in both RPA and Appian Process Modeler
• In RPA, the fields of the CDT can be accessed in the target menu or in any expression rule using dot notation

• In Appian process modeler, parameter variables can be mapped through the Data → Inputs

• For retrieving the status of the variables after the RPA process has run back to Appian Enterprise, the “Variables” data output map can be used to access all of the RPA process variables

Queueing Paradigm with Multiple Node Instances (MNI)

• To set up queueing in Appian RPA, the RPA process smart service must be used alongside setting up multiple node instances. One node must be run for every work item to be processed with RPA. For example:

• If work items are to be processed in the same VM and same browser window or windows application, the “Skip setup and clean up for consecutive executions” option can be selected for the RPA process (see below). However, the bot must be tested thoroughly to ensure that actions necessary for each execution are in the “main” section, while actions that need to be run at the start/end of the queue are placed in the setup/cleanup sections accordingly.
• For parallel queueing with more than one VM resource, the integration must be set up in Appian Enterprise to use the “first available resource” along with ensuring that the RPA process has access to the proper permission tags for every VM resource.

Technical Deployment

Automatic Sign In

• Appian RPA allows for sign-in directly from the RPA console (see documentation). This feature is useful when;
  • You need to execute the Agent using a non administrator user. If you start the agent from the console, the Windows session won’t get blocked
  • if you do not want to access manually to the windows machine to start the agent each time the computer is restarted.

Low Code Modules

Browser

• When fields or buttons are backed by javascript, sometimes, however, the get values or click actions don't work. In that case consider using:

List Flow

Application Security

• It's possible to enable site (Appian RPA) access based on the IP address of the incoming connection.
  • To enable trusted IP addresses, please create a support case and provide the IP addresses or block of IP addresses to be trusted.
  • Please refer to Configuring Trusted IP Addresses for Appian Cloud to learn more about adding IP addresses spaces to an allow list for your Appian Cloud environment(s) more Information

Other Automations

SAP Considerations

• When using RPA with SAP, be sure that the “Scripting” settings match what is shown below. Without this settings change, the SAP library cannot be used.