UiPath Automation Best Practice Guide Ui Path

User Manual:

Open the PDF directly: View PDF .
Page Count: 42

Download
Open PDF In Browser	View PDF

UiPath Automation Best Practice Guide
Table of Contents
•
•
•

•

•
•

1 Revision History
2 Table of Contents
3 Coding standards
o 3.1 Naming convention and strategy
o 3.2 Configurations
o 3.3 Credentials
▪ 3.3.1 Secure String
o 3.4 Error Handling
▪ 3.4.1 Try Catch
▪ 3.4.2 Throw
▪ 3.4.3 Rethrow
▪ 3.4.4 Terminate Workflow
▪ 3.4.5 Exception object (+ Data dictionary)
▪ 3.4.6 Business Rule Exception
▪ 3.4.7 Retry Scope
▪ 3.4.8 Debugging
o 3.5 Keep it clean
o 3.6 Source Control
▪ 3.6.1 SVN
▪ 3.6.2 TFS
4 Frameworks
o 4.1 REFrameWork
▪ 4.1.1 Principles
▪ 4.1.2 Refer to documentation
o 4.2 Enhanced REFrameWork Principles
▪ 4.2.1 Refer to documentation
o 4.3 Pilot Frameworks Principles
▪ 4.3.1 Refer to documentation
5
6 Workflow design
o 6.1 Design Principles (from Frameworks)
o 6.2 Layout Diagrams
▪ 6.2.1 Sequence
▪ 6.2.2 Flowchart
▪ 6.2.3 State Machine
o 6.3 Decisions
▪ 6.3.1 If Activity
o 6.4
▪ 6.4.1 Flow Decision
▪ 6.4.2
1

▪
▪
▪

6.4.3 If Operator
6.4.4 Switch Activity
6.4.5 Flow Switch

o
o

•

•

6.5
6.6 Data
▪ 6.6.1 Variable Scope
▪ 6.6.2 Arguments
▪ 6.6.3 Default values
o 6.7
o 6.8 Annotations and Comments
o 6.9 Workflow Abstraction Layers
o 6.10 Workflow templates
▪ 6.10.1 Workblocks
o 6.11 Reusability
o 6.12
o 6.13 How to Code Review
7 UIAutomation
o 7.1 Relating to the UI
▪ 7.1.1 Context vs Structure
o 7.2 Desktop Automation
▪ 7.2.1 Input Methods
▪ 7.2.2
▪ 7.2.3 Selectors
▪ 7.2.4 Finding UiElements
▪ 7.2.5 Containers
o 7.3 Image Automation
▪ 7.3.1 Resolution Considerations
▪ 7.3.2 Image Accuracy
▪ 7.3.3 OCR Engines
▪ 7.3.4 Image vs OCR
o 7.4 UI Synchronization
▪ 7.4.1 OnElementAppear
▪ 7.4.2 WaitElementVanish
o 7.5 Background Automation
8 Automation Lifecycle
o 8.1 Process Understanding
o 8.2 Documenting the process - DSD
o 8.3 Development and Code review
o 8.4 Test
▪ 8.4.1 Unit Test
▪ 8.4.2 Functional Test
▪ 8.4.3 Testing Framework
o 8.5 Release
o 8.6 Logging
▪ 8.6.1 Custom Log fields
o 8.7 Monitoring
2

•

9 Orchestrator
o 9.1 Multi tenant
o 9.2 Robots
o 9.3 Environments
o 9.4 Processes
o 9.5 Assigning Processes to Environments
o 9.6 Jobs
o 9.7 Schedules
▪ 9.7.1 Cron expressions
o 9.8 Queues
o 9.9 Transactions
o 9.10 Logs
o 9.11 API
▪ 9.11.1 2018.1 Studio Activities

Coding standards
Naming convention and strategy
Meaningful names should be assigned to workflow files, activities, arguments and variables in
order to accurately describe their usage throughout the project.
Firstly, projects should have meaningful descriptions, as they are also displayed in the
Orchestrator user interface. Moreover, adopting a good naming strategy for environments, assets
and queues makes the management of the virtual workforce in Orchestrator more manageable.
Only argument names are case sensitive, but to improve readability, variables and the other
entities should also align to the same naming convention.
•
•
•

Variables should be upper Camel Case, e.g. FirstName, LastName
Arguments should be in upper Camel Case with a prefix stating the argument type, e.g.
in_DefaultTimeout, in_FileName, out_TextResult, io_RetryNumber
Activity names should concisely reflect the action taken, e.g. Click ‘Save’ Button. Keep
the part of the title that describe the action (Click, Type Into, Element exists etc)

Except for Main, all workflow names should contain the verb describing what the workflow
does, e.g. GetTransactionData, ProcessTransation, TakeScreenshot

Variables
•
•
•

Use one variable for one and only one purpose.
Minimize the scope of each variable.
Keep statements that work with the same variable(s) as close together as possible.
3

•

•

•

•
•

Variables will always have meaningful names. The variable name should fully and
accurately describe the entity the variable represents. State in words what the variable
represents.
We will use upper Camel Case (Pascal case) for naming variables. This practice used
compound words, no other characters between the words, where each word will start with
a capital letter. Ex: TransactionNumber, FilePath, ReportName etc
The length of the variable name should be between 6 and 20 characters long. If you feel
that 20 characters are not enough, consider abbreviating longer words. Shorter variables
names can be used when using a local scope (like: index, file, row)
Datatable object: Start with dt_ prefix followed by the normal name. Ex: dt_Employees,
dt_Reports
Boolean type: Give Boolean variables names that imply True or False. You can use the
prefix is followed by the name. Ex. ApplicationExists, isRed, isFound etc. Always use
positive names, negatives names (Ex: notFound) should be avoided if possible.

Arguments
Same guidelines as for variables, with the below differences:
•

•

Each argument will have a prefix depending on the direction: in, out, io followed by the
underscore character ("_"). Example: in_Config, out_InvoiceNumber, io_RetryNumber,
in_dt_Employees
Use default values for arguments either for testing individual workflow files, or, in case
of reusable components, for using default configuration. When invoking a workflow file,
UiPath allows the flexibility to pass a value to any of the defined arguments, having
essentially all possible signatures defined by the argument list. This allows for using the
default value of an argument for which no value is passed upon invoking the file. Specify
what is the default configuration in the description of the reusable workflow file.

Activities
Activity names should concisely reflect the action taken, e.g. Click ‘Save’ Button. Keep the part
of the title that describe the action (Click, Type Into, Element exists etc). In case an activity
throws an exception the source of the exception will contain the activity name, so a proper name
to each activity is advisable for an easy understanding of the exception. Take extra care in
renaming activities that have a standard name, like Assign, If, For each or Sequence for which
the name doesn't automatically change - one would need to manually rename them.

Workflow files
•
•

Upper Camel Case naming
A workflow file starts with the prefix containing Application Name. E.g. for working in
SAP: SAP_Login.xaml, or SAP_ExtractClientReport. Typically, workflow files
4

•
•
•

belonging to the same application or system will be grouped together in one folder under
the project root folder. In case there are many files for one application, further
categorizing by using subfolders can be used.
When using a template framework - the framework files come already created and are
standard (including Main.xaml) - they should not be changed
When using a test framework - for the Test_Framework files – Use the prefix Test_ for a
workflow file that runs tests. Place these files in the Test_Framework folder
For an easier understanding, use number prefixes to emphasize the calling (invoking)
hierarchy of the Project, where the root is always Process (in REFrameWork) if the
hierarchy grows too large.

Projects and Sub-projects
•
•
•

Upper Camel Case naming
Group by department using a prefix: E.g. AP_, AR_
In case the process is automated using sub-processes (using multiple packages for the
same business process, like using Dispatcher and Performer), use the business process
code as the next prefix

Orchestrator
A good and consistent naming strategy must be used when defining the Orchestrator entities.
Robots
•
•
•

Development machines: DEV_[Name of developer in upper Camel Case] E.g.
DEV_DanielDines
Test machines: TEST_[Machine Name][Robot Number]
Prod machines: [Machine Name][Robot Number]

Environments
An environment links together multiple robots that are running the same process. Hence, the
naming will include a combination from robots and projects:
•
•
•

Use prefix DEV_ or TEST_ or PROD_
Group by department using a prefix: E.g. AP_, AR_
In case of sub-processes, use the business process code as the next prefix

Assets
•

for normal assets: [Department]_[Project code]_[Asset Name] E.g.
AR_CA_MappingTableURL
5

•

for credentials: C_[expiration period]_[Department]_[Project code]_[Asset Name] E.g.
C_180_AP_SC_SapCredentials

Queues
•

[Department]_[Project code]_[Queue Name] E.g. AR_CA_ExcelItems

Configurations
When automating processes, we will inevitably need to use configurations. We can categorize
the configurations into the following groups:
•

•

•

•

•

Configurations for which the values never change. Examples here would include a static
selector, or a label in an application. These ones should be hardcoded in the workflows.
There is not even a long term benefit from going through the trouble of storing them in a
file.
Configurations that are highly unlikely to change but are used into more than one place,
or settings that are important and are not meant to be changed by someone outside of the
development team. To allow extensibility and also increase readability, we recommend to
store these settings in a config file. Examples: Log messages, log fields, file or folder
paths and patterns. This way, if during development there is a need to change one of these
settings, they will be changed only in the config file. This technique also improves
readability as the key in the dictionary will have a meaning attached to the actual value
(E.g. using the "ReportID" key in the dictionary instead of the actual value: "12361223")
Configurations that are likely to change from one environment to another. Into this
category we have application paths, URLs, queue names, credential names etc. For these
settings we recommend using Orchestrator assets. The main advantage in this case is that
the values can be changed without modifying the code, so it allows the code developed
only in the Dev environment to migrate without changes into Test and then Production.
Runtime settings - This are required to be set during runtime. For Unattended robots we
should use Orchestrator assets, queues or external callouts, while for Attended robots,
this is achieved through input dialogs that request the necessary information.
Configurations that have different values for different robots - Use Orchestrator assets
with per robot value.

Generally speaking, the final solution should be extensible, to allow variations and changes in
the input data without an intervention from a developer, when required.

Credentials
Robot Credentials
6

Credentials are required by the Orchestrator to start an interactive Windows session on an
unattended robot. They are defined in the Orchestrator Robot definitions. The password in stored
encrypted with the 256 bit AES encryption algorithm and once set, the password cannot be
displayed. There's also the possibility of storing the passwords in CyberArk which is integrated
with Orchestrator.
Application Credentials
Application credentials should not be stored in the workflows or Config files in plain text, but
rather they should be loaded from safer places like local Orchestrator or Windows Credential
Store.
There are three ways of dealing with credentials natively in UiPath. They are displayed in the
order of recommendation:
•

•

•

Orchestrator Credential assets: They are stored securely in the SQL Server DB, with 256
bit AES. Once set, the password can't be displayed. They are retrieved using the Get
Credential activity under Orchestrator which returns a String Username and a
SecureString Password. It also supports per robot values, like normal assets. Due to the
increased security in the Orchestrator and global control, this is the recommended option.
In case using Orchestrator Credential assets is not possible, the second best option is to
use Windows Credential Store. Apart from getting the credentials, there's the possibility
to Add and Delete a credential from the store. There's also a Request Credential activity
for an Attended robot that creates a dialog at runtime designed to accept credentials.
Using the Windows Credential Store will imply the credentials are stored locally on the
robots and which means that in the case of deployment of a process on multiple robots,
one needs to create the same credential on all robots.
Using the Get Password activity - last resort option that stores the password encrypted in
the xaml file. The encryption is linked to the machine, so, for a successful decryption in
deployment it requires re-typing of the password and saving the xaml file. The code
cannot migrate without changes in this case.

The scope of the credential related variables, i.e. username and password should be limited to
where they are needed. Never use a larger scope for these variables.

Secure String
The password output from the GetCredentials activities is returned as a SecureString datatype.
This is a special class in the .NET Framework that represents text that should be kept
confidential. The password is not kept in plain text in memory, but rather obfuscated (not really
encrypted) which makes it difficult to find the password if someone or something is just
accessing the memory. Also, once the variable scope ends, the memory is immediately released,
unlike normal Strings. Once a SecureString is retrieved, it should be used to log into the
applications by using the Type Secure Text activity for normal applications or the Send Keys
Secure activity for Terminals.
7

For other activities that require authentication, like email activities or HTTP and SOAP Request
activities the password input type is String. In this case there's the following method to convert
the SecureString to a String:
String UnsecurePassword
SecureString SecurePassword
Assign:
UnsecurePassword = new System.Net.NetworkCredential("abc", SecurePassword).Password
The scope for the new UnsecurePassword, together with the SecureString password and String
username should be limited to where it's needed. The credential should not be used for any
purpose other than the intended one.

Error Handling
UiPath employs an exception handling mechanism very similar to what modern programming
languages permit. It is mainly focused on the Try Catch activity and, together with the Throw
activity, it enables an elegant error handling mechanism.
Two types of exceptions may happen when running an automated process: somewhat predictable
or totally unexpected. Based on this distinction there are two ways of addressing exceptions,
either by explicit actions executed automatically within the workflow, or by escalating the issue
to a higher level.
Exception propagation can be controlled by placing susceptible code inside Try Catch blocks
where situations can be appropriately handled. At the highest level, the main process diagram
must define broad corrective measures to address all generic exceptions and to ensure system
integrity. The REFrameWork has this exception handling mechanism in place and will recover
from any unexpected error.
Contextual handlers offer more flexibility for Robots to adapt to various situations and they
should be used for implementing alternative techniques, cleanup or customization of user/log
messages. If a block catches an exception it cannot handle, it is recommended to log the
exception and then rethrow the exception to the higher invoking level. Take advantage of the
vertical propagation mechanism of exceptions to avoid duplicate handlers in catch sections by
moving the handler up some levels where it may cover all exceptions in a single place. In the
REFrameWork this is the place is the Main.xaml workflow file.
Enough details should be provided in the exception message for a human to understand it and
take the necessary actions. The exception message and source are essential. The source property
of an Exception object will indicate the name of the activity that failed (within an invoked

8

workflow). Again, naming is vital - a poor naming will give no clear indication about the
component that crashed or about the source of the problem.

Try Catch
Any activity that may throw an exception should be part of the Try block in a Try Catch activity.
It is not necessary to be directly in the Try, there can be stand alone component that is not
handling exceptions (no Try Catch in it), but, when invoking it, it should be placed in the Try
block. There is only one exception from this rule: To set the status of a job as "Faulted" in the
Orchestrator in the case of an unattended robot, the Main file must end with an exception, i.e. it
should not finish the execution succesfully. This only applies when the job is triggered from
Orchestrator, otherwise the exception message popup is displayed on the screen. In this case
there might be some logic to throw an exception in the Main file if the job is considered to be
failed. In the REFrameWork, in the End Process state we have a Throw activity in case there's a
fatal error - like failing to initialize.
There can be multiple Catches and, in case of an exception, only the most specific Exception
will be caught and its handler executed. If the exception that is thrown in the Catch is not
contained in any of the defined catches, the exception will not be caught and will propagate
upwards. The Finally block will execute when the execution leaves the Try and the Catches
block.
Consider the following three scenarios in which there are three catches: System.Exception,
System.IO.IOException and System.IO.PathTooLongException:
1. In the first case PathTooLongException is thrown, so the catch that executes is
PathTooLongException as it is the exact match (most specific). Assuming no exception is
thrown in the catch, the Finally block will execute.
2. IO.FileNotFoundException is thrown, and the catch block executed is the IOException as
FileNotFoundException inherits from the IOException class, so it is the most specific.
3. SelectorNotFoundException is thrown, and the most generic System.Exception executes.
In fact, System.Exception will catch all exceptions, including custom defined ones. After
that, the Finally block executes.
4. SelectorNotFoundException is thrown, but there is no Catch that can handle this
exception. The exception is propagated upwards and Finally does not execute.
1.

9

Despite their usefulness, do not overuse the Try Catch activity. You should not catch an
exception unless you have a good reason for it. In most cases, the Catch will handle the
exception and recover from the error. There are some cases however, when an exception is
caught to perform some actions (like logging) and then the exception is rethrown to the upper
levels. This is a standard mechanism in the Workblock components of the Enhanced
REFrameWork (see below).

Throw
The Throw activity is used when the intended action is to throw an exception. This activity takes
an exception object input argument which can be created inline.
Another effect of using the Try Catch activity together with Throw is the reduction of decisions
(If statements), as well as the subsequent increase of readability. This is because of the
assumption that the code placed after the Try Catch activity will only be executed if no exception
was triggered.

Rethrow
In some cases, it may be necessary to return the exception to the normal flow by using the
Rethrow activity. This activity can only be used inside the Catch block of a Try Catch activity
and, as it does not receive any input, it uses the same exception that the Catch block caught.
A common use for Rethrow is when catching an exception for a particular action (for example,
logging) and rethrowing it for processing in upper levels.

Terminate Workflow
Exception object (+ Data dictionary)
Business Rule Exception

10

Business Rule exceptions can occur when an aspect of the process being automated does not
follow the expected flow (for example, a Robot needs to download an invoice from an email, but
the email has no attachments).
Differently from Application Exceptions, retrying Business Rule Exceptions automatically
would not be a good idea, since they usually depend on some external action in order to be
successful (for example, the invoice needs to be attached and the email resent). For this reason,
the Orchestrator does not automatically retry transactions that failed due to a Business Rule
exception. For more information, refer to the Orchestrator Guide.

Retry Scope
The Retry Scope activity provides away to try a block for a predefined number of times in case
there are any exceptions or a particular condition is not met. An important aspect of the Retry
Scope activity is that it reattempts to execute its contents without ending the workflow. In
addition, it does not throw exceptions unless the number of retries is reached. When checking
whether a particular condition is met, the activities IsTrue and IsFalse can be used in the
Condition block.
This activity is a powerful tool in cases where exceptions are thrown sporadically and other
measures, like tuning selectors, already took place. For example, a particular selector is not
found in a certain applications in less than 5% of the times the workflow runs, but no further
selector improvements are possible. Using Retry Scope in this scenario will make the robot try to
access the selector again in case a SelectorNotFoundException is thrown.

Debugging

Keep it clean
In the process flow, make sure you close the target applications (browsers, apps) after the Robots
interact with them. If left open, they will use the machine resources and may interfere with the
other steps of automation.
Before publishing the project, take a final look through the workflows and do some cleanup:remove unreferenced variables, delete temporary Write Line outputs, delete disabled code,
make sure the naming is meaningful and unique, remove unnecessary containers (Right-click
>Remove sequence).
The project name is also important – this is how the process will be seen on Orchestrator, so it
should be in line with your internal naming rules. By default, the project ID is the initial project
name, but you can modify it from the project.json file.
The description of the project is also important (it is visible in Orchestrator) - it might help you
differentiate easier between processes – so choose a meaningful description as well.
11

Source Control
In order to easily manage project versioning and sharing the work on more developers, we
recommend using a Version Control System.UiPath Studio is directly integrated with TFS &
SVN - a tutorial explaining the connection steps and functionalities can be accessed here.

SVN
TFS

Frameworks
Starting from a generic (and process agnostic) framework will ensure you deal in a consistent
and structured way with any process. A framework will help you start with the high-level view,
then you go deeper into the specific details of each process.

REFrameWork
The Robotic Enterprise FrameworkTemplate proposes a flexible high level overview of a
repetitive process and includes a good set of practices described in this guide and can easily be
used as a solid starting point for RPA development with UiPath. The template is built on a State
Machine structure.

12

Principles
How it works:
•
•
•
•
•
•
•
•
•
•

The Robot loads settings from the config file and Orchestrator assets, keeping them in a
dictionary to be shared across workflows
The Robot logs in to all applications, before each login fetching the credentials
It retries a few times if any errors are encountered, then succeeds or aborts
The Robot checks the input queue or other input sources to start a new transaction
If no (more) input data is available, configure the workflow to either wait and retry or end
the process
the UI interactions to process the transaction data are executed
If the transactions are processed successfully, the transaction status is updated and the
Robot continues with the next transaction
If any validation errors are encountered, the transaction status is updated and the Robot
moves to the next transaction
If any exceptions are encountered, the Robot either retries to process the transaction a
few times (if configured), or it marks the item as a failure and restarts
At the end, an email is sent with the status of the process, if configured
13

For transaction-based processes (e.g. processing all the invoices from an Excel file) which are
not executed through Orchestrator, local queues can be built (using .NET enqueue/ dequeue
methods).
Then the flow of the high-level process (exception handling, retrial, recovery) could be easily
replicated - easier than by having the entire process grouped under a For Each Row loop.
All the REFrameWork files, together with the documentation are found here:
https://github.com/UiPath/ReFrameWork

Refer to documentation

Enhanced REFrameWork Principles
Refer to documentation

Pilot Frameworks Principles
Refer to documentation

14

Project related files (e.g. email templates) could be organized in local folders or shared drives.
Note: If placed inside the project folder, they will be replicated during the deployment process (
together with the projects workflows) on all Robot machines under lib/net45 folder
These folders could be also stored on a shared drive - so all the Robots will connect to the same
unique source. This way, the process related files could be checked and maintained by the
business users entirely, without support from the RPA team. However, the decision (shared or
local folders) is complex and should take into consideration various aspects related to the process
and environment: size of the files, frequency of changes, concurrency for editing the same file,
security policies etc.

Workflow design
15

Design Principles (from Frameworks)
Breaking the process in smaller workflows is paramount to good project design. Dedicated
workflows allow independent testing of components while encouraging team collaboration by
developing working on separate files.
Choose wisely the layout type - flowcharts and sequences. Normally the logic of the process
stays in flowcharts while the navigation and data processing is in sequences.
By developing complex logic within a sequence, you will end up with a labyrinth of containers
and decisional blocks, very difficult to follow and update.
On the contrary, UI interactions in a flowchart will make it more difficult to build and maintain.

Layout Diagrams
UiPath offers three diagrams for integrating activities into a working structure when developing
a workflow file:
•
•
•

Flowchart
Sequence
State Machine

Sequence
Sequences have a simple linear representation that flows from top to bottom and are best suited
for simple scenarios when activities follow each other. For example, they are useful in UI
automation, when navigation and typing happens one click/keystroke at a time. Because
sequences are easy to assemble and understand they are the preferred layout for most workflows.

Flowchart
Flowcharts offer more flexibility for connecting activities and tend to lay out a workflow in a
plane two-dimensional manner. Because of its free form and visual appeal, flowcharts are best
suited for showcasing decision points within a process.
Arrows that can point anywhere closely resemble the unstructured GoTo programming statement
and therefore make large workflows prone to chaotic interweaving of activities.

State Machine

16

State Machine is a rather complex structure that can be seen as a flowchart with conditional
arrows, called transitions. It enables a more compact representation of logic and we found it
suitable for a standard high level process diagram of transactional business process template.

Decisions
Decisions need to be implemented in a workflow to enable the Robot to react differently in
various conditions in data processing and application interaction. Picking the most appropriate
representation of a condition and its subsequent branches has a big impact on the visual structure
and readability of a workflow.

If Activity
The IF activity splits a sequence vertically and is perfect for short balanced linear branches.
Challenges come when more conditions need to be chained in an IF… ELSE IF manner,
especially when branches exceed available screen size in either width or height. As a general
guideline, nested If statements are to be avoided to keep the workflow simple/linear. Using the
Collapse feature can help improve the readability.

Flow Decision
Flowchart layouts are good for showcasing important business logic and related conditions like
nested IFs or IF… ELSE IF constructs. There are situations where a Flowchart may look good
even inside a Sequence, e.g. the Robot Retry Flowchart in the SetTransactionStatus xaml file
from the REFrameWork.

17

If Operator
The VB If operator is very useful for minor local conditions or data computing, and it can
sometimes reduce a whole block to a single activity. This might decrease the readability and
should be used only for specialized code that acieves a certain function not necessarily important
to the whole context. Make sure that the activity using the VB If operator is properly named or
annotated.

Switch Activity
Switch activity may be sometimes used in convergence with the If operator to streamline and
compact an IF… ELSE IF cascade with distinct conditions and activities per branch.

18

Flow Switch
Flow Switch selects a next node depending on the value of an expression; FlowSwitch can be
seen as the equivalent of the procedural Switch activity in the Flowchart world. It can
matchmore than 12 cases by starting more connections from the same switch node.

Data
Data comes in two flavors when it comes to visibility and life cycle: arguments and variables.
While the purpose of arguments is to pass data from one workflow to another, variables are
bound to a container inside a single workflow file and can only be used locally.

19

Variable Scope
Unlike arguments, which are available everywhere in a workflow file, variables are only visible
inside the container where they are defined, called scope.
Variables should be kept in the innermost scope to reduce the clutter in the Variables panel and
to show only, in autocomplete, what is relevant at a particular point in the workflow. Also, if two
variables with the same name exist, the one defined in the most inner scope has priority.

Arguments
Keep in mind that when invoking workflows with the Isolated option (which starts running the
workflow in a separate system process), only serializable types can be used as arguments to pass
data from a process to another. For example, SecureString, Browser and Terminal Connection
objects cannot safely cross the inter-process border.

Default values
Variables and input arguments have the option to be initialized with some default static values.
This comes in very handy when testing workflows individually, without requiring real input data
from calling workflows or other external sources.

Annotations and Comments
The Comment activity and Annotations should be used to describe in more detail a technique or
particularities of a certain interaction or application behavior. Keep in mind that other people
may, at some point, come across a robotic project and try to ease their understanding of the
process.

Workflow Abstraction Layers
20

Workflow templates
Workblocks

Reusability
When developing, we often need to automate the same steps in more than one workflow/ project,
so it should be common practice to create workflows that contain small pieces of occurring
automation and add them to the Library.
There is no universal recipe that tells you how to split any given process.
However, separation of business logic from the automation components is good principle that
will help with building a code that can be reused effectively.
Example
Let’s assume that a part of your process requires reading the customer info, then – based on that
info and internal business rules - update the customer details.
"Get Customer Info" and "Change Customer Info" should be two distinct automation
components, completely agnostic of any process. The logic (eg. update the customer type only
when total amount is > 100k in the last 12 months) should be kept separated from automation.
Both components could be used later, separately, in the same project or in a different one, with a
different logic. If needed, specific data could be sent to these components through arguments.
"Change Customer Info" should not be invoked from within "Get Customer Info" - as this will
make it more difficult to test, handle exceptions and reuse.

21

When separation between actions is not that obvious, copy - pasting existing code from one
workflow to another (or from one project to another) – is also a good indication that you should
build a separate component (workflow) for the code and invoke it when needed.
Where to store reusable components
Dragging and dropping existing code from the Library to a workflow is easier than recreating
the code from scratch, again and again. Dealing with data (Sorting, Filtering) or with text
(Splitting, Regex patterns) are examples of what could be added to the sample library. But make
no confusion – once the code is added to the workflow, this will be static - if you update the
workflow in the Library, it won’t be reflected in the existing live processes.
Common (reusable) components (e.g. App Navigation, Log In, Initialization) are better stored
and maintained separately, on network shared drives. From that drive, they can be invoked by
different Robots, from different processes. The biggest advantage of this approach – improved
maintainability – is that any change made in the master component will be reflected instantly in
all the processes that use it.
An example of reusable content implementation - on release chapter

How to Code Review
Modularity
•
•

Separation of concerns with dedicated workflows allows fine granular development and
testing
Extract and share reusable components/workflows between projects

Maintainability
•

Good structure and development standards

Readability
•
•

Standardized process structure encouraging clear development practices
Meaningful names for workflow files, activities, arguments and variables

Flexibility
•

Keep environment settings in external configuration files/Orchestrator making it easy to
run automation in both testing and production environments

Reliability

22

•
•

Exception handling and error reporting
Real-time execution progress update

Extensible
•

Ready for new use cases to be incorporated

UIAutomation
Sometimes the usual manual routine is not the optimal way for automation. Carefully explore the
application’s behavior and UiPath’s integration/features before committing to a certain approach.

Relating to the UI
Context vs Structure

Desktop Automation
UI automation goes at its best when Robots and applications run on the same machine because
UiPath can integrate directly with the technology behind the application to identify elements,
trigger events and get data behind the scenes.

Input Methods
There are three methods UiPath uses for triggering a Click or a Type Into an application. These
are displayed as properties in all activities that deal with UI automation.
•
•

•

If SimulateType or SimulateClick are selected, Studio hooks into the application and
triggers the event handler of an indicated UI element (button, edit box)
If SendWindowMessages is selected, Studio posts the event details to the application
message loop and the application’s window procedure dispatches it to the target UI
element internallyconfluence
Studio signals system drivers with hardware events if none of the above option are
selected and lets the operating system dispatch the details towards the target element

23

These methods should be tried in the order presented, as Simulate and WindowMessages are
faster and also work in the background, but they depend mostly on the technology behind the
application.
Hardware events work 100% as Studio performs actions just like a human operator (e.g. moving
the mouse pointer and clicking at a particular location), but in this case, the application being
automated needs to be visible on the screen. This can be seen as a drawback, since there is the
risk that the user can interfere with the automation.

Selectors
Sometimes the automatically generated selectors propose volatile attribute values to identify
elements and manual intervention is required to calibrate the selectors. A reliable selector should
successfully identify the same element every time in all conditions (e.g., development, test and
production environments) and no matter the usernames logged on to the applications. In other
words, it must be specific enough to uniquely identify interface elements, but also generic
enough to work even if there are a few changes on the screen.
Here are some tips of how to improve a selector in Selector Editor or UiExplorer:
•
•
•
•
•

Replace attributes with volatile values with attributes that look steady and meaningful
Replace variable parts of an attribute value with wildcards (*)
If an attribute’s value is all wildcard (e.g. name=’*’) then attribute should be removed,
since it would not contribute to restricting the search for the element.
If editing attributes doesn’t help, try adding more intermediary containers (e.g., Attach
Browser and Attach Window) to help restricting the search for the element.
Avoid using idx attribute unless it is a very small number like 1 or 2

24

In the selector above, we notice the page title has a reference to the time when selector was
recorded and also that some attributes have randomly looking IDs. Tweaking the attributes, we
can come up with a better selector than UiPath recorder proposed.

Wildcards
Wildcards can be used to make a part of an attribute more generic. For example, if the title of a
window is represented by title='Calendar May 28, 2018', the selector will not work if the date
changes. In these cases, it is better to use a wildcard to replace the date part, which will indicate
that the selectors should find all windows whose title begins with the word Calendar.
The excessive use of wildcards can make the selector too generic and match more than one
element, so in some situations it is necessary to combine it with other attributes or other
techniques to define selectors.
IDX
The idx attribute should be used carefully. The value of the idx attribute represents the index of a
particular element that has the same selector as elements on the screen. There might be some
undesired behavior when using the idx attribute since the index can change with the order of
appearance of such elements. For this reason, it is recommended not to use this attribute, unless
it is a small number like 1 or 2.
The 

---

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.7
Linearized                      : No
Page Count                      : 42
Language                        : en-US
Tagged PDF                      : Yes
XMP Toolkit                     : 3.1-701
Producer                        : Microsoft® Word 2016
Title                           : UiPath Automation Best Practice Guide
Creator                         : Lavinia Nastase
Creator Tool                    : Microsoft® Word 2016
Create Date                     : 2018:08:01 13:41:14+03:00
Modify Date                     : 2018:08:01 13:41:14+03:00
Document ID                     : uuid:34F93659-056B-4385-A809-E98A963CA2C4
Instance ID                     : uuid:34F93659-056B-4385-A809-E98A963CA2C4
Author                          : Lavinia Nastase

EXIF Metadata provided by EXIF.tools