Effective Naming Conventions in UiPath: A Comparative Analysis

Using effective naming conventions is vital for clear code, teamwork, and debugging. It also plays a crucial role in maintaining automation scripts and frameworks.

This article discusses an approach to naming and folder structure in a UiPath library project with an Object Repository. It provides insights for automation engineers and teams looking to improve their RPA practices.

Let’s analyze the approach used at Flobotics, considering its pros and cons and identifying what to avoid!

An Object Repository is a part of a Library project that enables the creation of a set of reusable user interface elements. The Object Repository ensures the management, reusability, and reliability of UI elements by capturing them as objects in a DOM-like repository, shareable across projects. It allows for creating and reusing UI taxonomies inside and across automation projects.

Some key features of the Object Repository include:

• UI elements across the project are managed, updated, and modified from a centralized place
• Drag-and-drop elements from the Object Repository panel
• Objects are reusable in a local project or across projects when packaged as libraries

These key features are why, at Flobotics, we employ the Object Repository as a project practice.

In the next step, we will show the practical implementation of the theoretical assumptions. We will present internal principles, naming conventions, and a specific usage example.

Before we started building the nomenclature standard, we assumed that the application operates in a single web browser. A developer should include this information in the project description. The current approach used in Flobotics follows the naming scheme:

Application -> [Application name]
Example:
NameCRM

Screen -> [Screen name]
Examples:
Login
PPList

Element -> [Element type]_[Element name] (For dynamic selectors, it is recommended to add the prefix “Dyn” to increase readability.)
Examples:
Button_Login
Link_Dyn_SettlementId
Checkbox_PPRow

[OPTIONAL]
Group -> Group_[Group name]
Examples:
Group_MessageBox
Group_Common

A screenshot showing the object repository project

According to the assumption, using the object repository should make work easier. In the chosen naming convention, we prioritize simplicity and clarity. For more complex elements, we suggest adding a description to the element.

A library is a project that contains one or more workflows that can be reused as activities in other projects. Libraries are saved as NUPKG files when published and can be installed as dependencies from the Package Manager.

When creating a library, it’s advisable to follow the same principles we employ for the Object Repository. The names of individual tree elements should be precise and clear. It’s crucial to define and establish the project structure early on, even for complex applications. Changing the workflow name or path affects the project using the library.

In the diagram below, we have introduced an approach that is consistent with the expectations discussed in the previous chapter. The naming convention is business-oriented:

Folder -> [Application name]_[Screen name]
Example:
NameCRM_Login

Workflow -> [Screen name]_[Action name]
Example:
SettlementList_ClickClearFilter
SettlementList_FillPPNumber

A screenshot showing the library project

Let’s now explore the approach’s pros and cons, which we have drawn from observations and practical use.

In this article section, we’ll discuss what to avoid when setting up the Object Repository and library:

• A technical approach in which activity names do not reflect the business context,
• Repetitive xaml names – Click.xaml, Click.xaml, Click.xaml, hard to work on and easy to get wrong,
• Restrictions on use, approach in which we can not add more than one action to the activity,
• The naming convention that causes difficulty in navigation when building a process – filtering by name returns a lot of similar results,
• Artificial granularity of activities, for example, where one activity is responsible for inputting values (Type into), and another is for verifying execution (Check App State, Get text).

The proposed naming convention approach has met the Object Repository and library project objectives. Clarity, ease of use, and maintainability of such projects should be a priority.

We have applied this approach, demonstrating its versatility in various projects. It has proven effective on both small and large scales.

If you are eager to delve deeper into UiPath’s features, consider exploring our article on task mining capabilities in UiPath. Additionally, you can gain valuable insights by comparing UiPath with other automation tools such as Blue Prism, Power Automate, or Google Cloud. Stay informed and empowered in your automation journey.