This PPT provides insights on UiPath Development Best Practices.

1. Development
Best Practices
Final session on UiPath development best practices
which need to be followed during a process
automation journey

2. 2
Agenda
01 Why UiPath Best Practices Matter?
02 Naming Conventions
03 Error Handling
04 Reusability
05 Workflow Design
06 Logging
07 Configurations
08 Security
09 UI Automation Best Practices
10 Some General Tips and Tricks
11 Q&A
12 Quiz

3. 3
Why UiPath Best Practices Matter?
• Quality: Following UiPath best practices can help improve the quality of your workflows. By using consistent naming
conventions, modular design, and error handling, you can create workflows that are easier to understand, maintain,
and scale.
• Maintainability: Best practices can also make workflows easier to maintain over time. By using modular design,
commenting your code, and following consistent naming conventions, you can make it easier for other developers to
understand your code and make updates as needed.
• Scalability: Best practices can also make workflows easier to scale. By using modular design and reusability, you
can create workflows that can be easily modified and adapted for different use cases without having to rewrite the
entire workflow.
• Efficiency: Following UiPath best practices can also help improve the efficiency of your workflows. By optimizing
selectors, reducing the number of activities used, and avoiding unnecessary delays, you can create workflows that
run faster and use fewer resources.
• Consistency: Best practices can help ensure consistency across your workflows. By using consistent naming
conventions, design patterns, and error handling, you can create workflows that are easier for other developers to
understand and work with.
• Compliance: Following best practices can also help ensure compliance with security and regulatory requirements.
By encrypting sensitive data, using secure credentials, and limiting access to workflows, you can help protect your
organization's data and ensure compliance with relevant regulations.

4. 4
Naming Conventions – Why it is important?
• Consistency: Standard naming conventions ensure consistency throughout the project(s), making it easier for
developers to understand and work with each other's code.
• Maintainability: Meaningful names for workflow files, activities, arguments, and variables make it easier to
maintain the project(s) over time.
• Readability: A consistent naming convention improves the readability of the code, making it easier to
understand and troubleshoot.
• Management: A good naming strategy for environments, assets, and queues makes management in
Orchestrator easier.
Overall, standard naming conventions help to improve the quality of the code and make it easier to manage and
maintain UiPath projects.

5. 5
Naming Conventions - Variables
• Upper Camel Case (PascalCase) should be used for variables with
compound words, no other characters between the words, and each
word starting with a capital letter.
• One variable should be used for one purpose only, and global
variables should be avoided to minimize their scope.
• Variables should be kept in the innermost scope to reduce clutter in
the Variables panel and show only relevant options in autocomplete.
• Meaningful names should always be used for variables that fully and
accurately describe the entity they represent, and words should be
used to state what the variable represents.
• Lengthy variable names should be avoided and if the variable
name exceeds 20 characters, longer words can be abbreviated.
Shorter meaningful variable names can be used when using a local
scope, such as in a Foreach activity with variable names like index,
file, or row.
• Boolean variables should be constructed with prefixes - ‘Is’ or ‘Has’
followed by the name which should be meaningful like –
IsLoginButtonExists. Negative names like NotExists should be
avoided.
• Data table variable names should have the prefix or suffix Dt, like
TransactionDetailsDt or Dt_SAPTable.

6. 6
Naming Conventions - Arguments
• All arguments should be defined in Upper Camel Case with a prefix stating the argument type, for example
in_DefaultTimeout, in_FileName, out_TextResult, io_RetryNumber.
• Each argument should have prefix depending on the direction: in, out, io followed by the underscore character
("_"). Examples: in_Config, out_InvoiceNumber, io_RetryNumber.
• You can use default values for arguments for testing individual workflow files. Ensure to delete the default values
for arguments inside the workflow files in the project before publishing the project.
• Lengthy argument names should be avoided. In case of lengthy argument names , longer words can be
abbreviated.
• For readability and maintenance purposes, avoid having too many arguments for a single workflow file / reusable
component.

7. 7
Naming Conventions - Activities
• It is recommended to rename all activities name in a project and not to leave the default name for activities.
• Ensure to rename all activities in a project, including Log Message, Assign, If, and Sequence, to improve readability
and facilitate error handling.
• Activity names should describe the action taken, such as - Click ‘Login' Button or Type Into ‘Account Number’.
• Properly naming each activity is advisable as it helps to easily identify the source of an exception if an activity
throws one.

8. 8
Naming Conventions – Workflow Files
• Use Upper Camel Case naming convention for workflows to improve readability.
• Workflow files should be prefixed with the application name and should also contain a verb to indicate the task
it is performing. For example, SAP_Login.xaml or SAP_SearchTransactions.xaml. when working with SAP.
• All workflow files belonging to the same application or system should be stored in one folder under the project root
folder.
• While creating a test workflow, please use the prefix “Test_” for a test workflow file and all these test workflow files
should be placed in the Test_Framework folder.

9. 9
Error Handling – Business Rule Exceptions
Automation Error can be of 2 types –
 Business Rule Exceptions or Expected exceptions
 System or Application Exceptions or the Unexpected exceptions
 Business Rule Exceptions (BRE) –
 Always related to process data and business logic
 Occurs when some parts of the automation does not follow
the expected route
 Best Practices for Business Rule Exceptions –
 Meaningful messages should be passed as Business
Rule Exception. For Example – New
BusinessRuleException( "The sum of transaction items,
"+ TransactionSum + ", exceeds the maximum allowed
value of "+ManualTransactionThreshold)
 It is NOT recommended to retry a transaction in case of
any Business Rule Exception.
 Appropriate Log Message activities and Throw activities
should be used to log the business rule exceptions with
the correct exception message.

10. 10
Error Handling – System or Application Exceptions
 Application Exceptions –
 Related to applications that robot interacts with. It can be due
to application stops responding or No internet connection.
 Occurs when automation fails unexpectedly.
 Best Practices for Application Exceptions –
 Identify the activities which might fail with system
exceptions and wrap them inside a Try/Catch activity to
catch these kind of errors.
 Appropriate Log Message activities should be used to
log the exception message with the correct exception
message.
 Set Transaction Status activity should be set to
ApplicationException and the Auto Retry option in the
Create Queue page should be set to Yes when the
queue is created – this will ensure that the queue item
will get retried.
 If you do not use Queues, ensure you have a logic to
auto-retry the failed transactions.

11. 11
Error Handling – General tips for exception handling
 Proper logging levels should be used in Log Message activities in
case of exceptions.
 Retry scope activity to be used to try a block for a predefined
number of times in case there are any exceptions, or a particular
condition is not met.
 Retry Scope will throw an exception if the retry number is exceeded.
Therefore, it should be placed in a Try Catch, with a proper Log
Message in the Catch section.
 Global Exception Handler should be used to retry failed activities. It
can be created from the project panel.

12. 12
Reusability
 Design workflows to be modular and self-contained, with clear inputs and outputs that can be easily configured for
different use cases.
 While designing the library components, it is always best practice to keep the business logic separate from Library
components. For example – In the below example, "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.
 Use descriptive and meaningful names for workflows, activities, and variables to make it easier for others to understand
and reuse them.
 Use the UiPath Library feature to store and manage reusable workflows and components, making it easier to share them
across the organization.
 Test reusable workflows thoroughly to ensure they work as expected in different scenarios and use cases.
 It is recommended to have a library for every application.

13. 13
Workflow Design – Sequences Vs Flowcharts
 Choose the right layout type - Flowcharts or Sequences - for your workflow to make it easier to understand and maintain.
 Sequences :
 Sequences are best suited for simple scenarios where activities follow each other in a linear fashion, such as UI
automation tasks.
 Lengthy sequences should be avoided as they can become difficult to understand, debug, and maintain over time.
 Instead of building lengthy sequences, aim to split the logic into atomic workflows containing no more than 15 to 20
activities.
 Each workflow should contain only one piece of logic to avoid mixing different types of logic in the same file. For
example, instead of combining navigation, file downloading, and data filtering in the same workflow, build separate
workflows for each atomic piece of logic.
 Flowcharts :
 Flowcharts are more flexible than sequences and are best suited for workflows that involve multiple decisions.
 Sequences of steps should be grouped into workflows and invoked from the flowchart to improve readability and
maintainability.
 The flowchart should be designed to be similar to the TO BE diagram in the PDD for even better readability.
 By using flowcharts in the right way, workflows can be designed to be more flexible, easier to understand, and
more maintainable over time.

14. 14
Workflow Design – Best Practices
 Avoid using nested IF conditions as they can make the workflow
hard to read and understand.
 If you have more than two levels in the nested IF condition,
consider using a Flowchart or breaking the conditions into
multiple conditional statements on the same level.
 Avoid using nested Flowcharts as they can make the workflow
hard to read and manage.
 Use a Sequence when using UI Automation as the actions get
executed sequentially, making it easier to understand and
maintain.
 Avoid overloading a workflow file with too many actions; instead,
break it into multiple workflows. Break the workflow into subtasks
or subprocesses to improve readability and maintainability.
 Use separate workflow files for subprocesses and use Invoke
Workflow activities to invoke them from a central control workflow
when necessary.
By following these best practices, workflows can be designed to be
more modular, easier to understand, and less prone to errors and
bugs.

15. 15
Logging – Best Practices
 Log Message activities should be used to trace a running process
for supervising, diagnosing and debugging a process. Messages
should provide all relevant information to accurately identify a
situation, including transaction ID and state.
 As a best practice, logging should be used:
 at the beginning and the end of every workflow (Log level =
Information)
 each time an exception is caught in a Catch block (Log level
= Error);
 each time a Business Rule Exception is thrown (Log Level =
Error);
 when data is read from external sources (for example, log a
message at Information level when an Excel file is read) (Log
Level = Information);
 in Parallel or Pick activities, log messages on every branch,
in order to trace the branch taken (Log Level = Information);
 in If/Flowchart Decision/Switch/Flow Switch activities

16. 16
Configurations – Best Practices
 Different types of configurations need to be stored differently in UiPath projects –
 Configurations with values that never change, such as static selectors or application labels, should be
hardcoded in the workflows.
 Configurations that are unlikely to change but used in multiple places or important settings not meant
to be changed by anyone else except the development team should be stored in a config file for
extensibility, reusability, and readability. Examples include - file or folder paths
 Configurations that are likely to change from one environment to another, such as application paths or
queue names, should be stored in Orchestrator assets to allow values to be changed without modifying
the code.
 Runtime settings should be set during runtime using Orchestrator assets or queues for unattended
robot and input dialogs for attended robots.
 Configurations with different values for different robots should use Orchestrator assets with per-
robot values. For example –Storing different user login credentials for the same application for different
processes
 The final solution should be extensible to allow changes in input data without developer intervention.
 Configuration files can be stored in Excel or JSON files or even as assets in Orchestrator.
By following these best practices, workflows can be designed to be more modular, easier to understand
and maintain, and less prone to errors and bugs.

17. 17
Security – Storing of Credentials
 Application Credentials should not be stored inside workflow files or config files in plain text.
 Credentials should be stored as Orchestrator Credential Assets either in Orchestrator Assets
or Windows Credential Store.
 Following are the ways in which credentials should be stored –
 Orchestrator Credential Assets (Most Recommended)
 If Orchestrator is not available, Windows Credential Store is the next best option.
 To fetch the credentials from Orchestrator Assets, Get Credential activity should be used
which returns the credentials as SecureString datatype and it should be kept confidential.
 To fetch the credentials from Windows Credential Store, Get Secure Credential activity should
be used
 The scope of the credential variable returned through these activities should always be limited
to where it’s needed.

18. 18
Using Annotations/Comments
 Every workflow should have annotations at the top describing the purpose of that workflow. It
should contain the following sections –
 Description of the task being performed
 Input Arguments and their data type
 Output Arguments and their data type
 Pre-Conditions describing the expected state before starting the steps.
 Post-Conditions describing the expected state after completing the steps.
Courtesy : https://www.c-sharpcorner.com/article/uipath-rpa-design-best-practices/

19. 19
Using Annotations/Comments (contd..)
 Comments activity should be used where necessary to explain the details of the process
steps.
 Annotations can also be used for variables and arguments describing their purpose and usage
within the workflow. You can also add annotations for variables through the variables panel
and for arguments through the arguments panel.

20. 20
Ui Automation Best Practices
 Avoid Delays in workflow :
 Avoid using any hardcoded values in the workflow files unless it is specifically required for the workflow to
run.
 All timeouts should be kept in the config file.
 Avoid using Delay activity in a workflow where the application takes time to respond.
 In scenarios where an application takes time to respond to robot interactions, following activities should be
used to check the state of application before proceeding with further steps –
 ElementExists, ImageExists, Text Exists, OCR Text Exists
 FindElement, Find Image, Find Text
 WaitElementVanish, WaitImageVanish
 Try to perform UI Automations in Background :
 For scenarios where an automation is intended to share the desktop with human user, all UI Interactions
must happen in background. Following strategies help the automation to run in background meaning
automation will work with UI objects even when the window is minimized –
 Use the SimulateType, SimulateClick and SendWindowMessages options for navigation and data
entry via the Click and TypeInto activities
 Use the SetText, Check and SelectItem activities for background data entry
 GetText, GetFullText and WebScraping are the output activities that run in the background
 Use ElementExists to verify application state

21. 21
Ui Automation Best Practices (contd..)
 Keep the Selector as dynamic and steady as possible :
 Recommended to use attributes which are steady and meaningful.
 Remove all attributes which are having all wildcard (e.g. name=’*’) since it would not contribute to
restricting the search for the element.
 Avoid using idx parameter in a selector of any element as it is prone to change in future.
 Use wildcards to make the selector dynamic. For example, if the title of a window is represented by
title='Calendar July 30, 2023', the selector will not work if the date changes.
 Use dynamic selector for scenarios where you need to match an element based on runtime values. For
example, using the same selector, all of the data in a table can be identified, using the column and the row
variables.

22. 22
Some General Tips and Tricks
 For scenarios where robot needs to perform certain steps iteratively for set of
transactions in an application – Launching of application and login of
application should be performed only once outside the for each loop.
 Once the entire process is complete for all the transactions, make sure you
close the target applications (browsers, apps) after the robots interact with
them.
 For Excel automation –
 Always choose Workbook activities instead of Excel Scope, since they
do not require Excel to be installed on the machine.
 Excel Scope might be more helpful in certain cases as it provides more
functionalities.
 If Excel reporting is required, avoid updating it after each transaction and
choose to have a separate process to gather the data at the end of the
process and update the excel report.
 Don’t overuse Try-Catch activity for error catching –
 In case of Data table filtering operation in an assign activity, the activity
will throw and exception in case the table is empty. Instead of putting
this assign activity in Try block, it can be checked by using a simple If
condition.
 In case of UI automations, instead of performing all operations in a Try
block, it’s a good practice to check availability of target elements using
Element Exists, Find Element, Check App State etc.

23. 23
Some General Tips and Tricks (contd..)
 Remove unused dependencies from the through the Dependency Manager.
 Clean up all the unused variables from the solution using the Remove Unused Variables option.
 Use the Workflow Analyzer to build your design rules and standards to address all the best
practices. The Workflow Analyzer can be accessed from the Design ribbon in UiPath Studio.
Workflow Analyzer consists of multiple rules which you can configure according to your best
practices followed.

24. 24
Quiz
1. Go to https://www.menti.com/
2. Type the code : 4831 0772
OR
Scan the QR code below :

25. 25
Q&A