RPA UiPath

Project Organization in Studio (UiRPA part 12)

About the course

In this course, we will focus on best practices for organizing your projects. We will learn about selecting project layouts, breaking down complex processes, reusing parts of a project, managing versions of the components, and preventing exceptions.

What you will learn in this course

At the end of this course you will be able to:

  • Choose a suitable project layout for each workflow.
  • Split a complex automation project into functional workflows that can be developed separately.
  • Create and share project templates to speed up development.
  • Identify reusable components across projects and store them as libraries for future reuse.
  • Explain the benefits of using exception-handling techniques.
  • Explain the benefits of using the versioning capabilities of UiPath to keep the development effort trackable and reliable.

Every UiPath implementation needs to follow clear principles.

Our purpose is to build automated processes that are:

  • Reliable: robots should work as expected, with a minimum rate of unexpected errors.
  • Efficient: the execution time should be minimized as much as possible.
  • Maintainable: the workflows should be easy to understand and debug.
  • Extensible: it should be easy to add new features.

Choosing the Workflow Layout

For small processes automated or parts of a larger automation project, there are three options of layout – Sequence, Flowchart and State Machine.


When to use it?

  • When there’s a clear succession of steps, without too many conditions (for example, UI automation).
  • Usually, sequences are used to nest workflows and the high-level logic is handled through flowcharts or state machines.

What are the advantages?

  • Easy to understand and follow, having a top to bottom approach.
  • Great for simple logic, like searching for an item on the internet.

What are the disadvantages?

  • Nesting too many conditions in the same sequence make the process hard to read.
  • Not suitable for continuous flows.


When to use it?

  • When you have a complex flow with several conditions, a flowchart is at least visually much easier to understand and follow.
  • When you need a flow that terminates only in one of several conditions.

What are the advantages?

  • Easy to understand, as it is similar to logic diagrams in software computing.
  • The most important aspect of flowcharts is that, unlike sequences, they present multiple branching logical operators, that enable you to create complex business processes and connect activities in multiple ways.

What are the disadvantages?

  • Flowcharts should be used only as the general workflow (with sequences nested inside), not for individual parts of projects (nested inside other workflows).

State Machine:

When to use it?

First of all, let’s understand what a state machine is. It is an abstract machine consisting of a finite number of pre-defined states and transitions between these states. At any point, based on the external inputs and conditions verified, it can be in only one of the states.

State machines can be used with a finite number of clear and stable states to go through. Some examples from your daily life include vending machines, elevators or traffic lights.

What are the advantages?

  • Can be used for continuous workflows that are more complex.
  • Transitions between states can be easily defined and offer flexibility.
  • Can accommodate processes that are more complex and cannot be captured by simple loops and If statements.
  • It is easier to cover all the possible cases/transitions with state machines.

What are the disadvantages?

  • Longer development time due to their complexity: splitting the process into logical “states”, figuring out transitions, and so on.

Note: State machines are not to be overused – they should define only the skeleton of the project.

In fact, there are templates built upon state machines specially designed to build large enterprise automation. The most commonly used is the Robotic Enterprise Framework.

Organizing Projects in Workflows

There are multiple ways in which the workflows can be split and at least 3 factors should be considered as breakdown criteria:

  • The application that is being automated.
  • The purpose of a certain operation (login, processing, reading a document using OCR, filling in a template, and so on).
  • The complexity of each workflow.
  • Workflow reusability in other projects.

For example, a complex process can be split into workflows for each application, and for each of those applications, split on input, processing or output. If any of these workflows are too complex, they can be further split, having in mind also a purpose to do it.

Handling data in projects with multiple workflows

Splitting a project into smaller workflows has an influence on how data is handled. Since variables work only inside the same workflow, having more than one workflow requires arguments.

As you probably know from the Variables, Data Types, and Control Flow in Studio course, Arguments are very similar to variables – they store data dynamically, they have the same data types, and they support the same methods. The main difference is the ‘Direction’ property, signifying the direction from/to which the data is passed. The direction can be In, Out and In/Out:

  • In – if we want to pass a value to be used only inside the invoked workflow.
  • Out – if we want to pass a value to be used outside of the invoked workflow, in the parent workflow.
  • In/Out – if we want to pass a value from the parent workflow to the invoked workflow, modify it in the invoked workflow and then pass the new value back to the parent workflow.

Note: When the ‘Extract as Workflow’ action is used, variables are automatically turned into arguments.

Best practices for using arguments

  • Naming: Use the direction as a prefix when naming arguments – e.g. in_ArgumentName1, out_ArgumentName2, io_ArgumentName3.
  • Directions: Be specific with argument directions. Avoid using In/Out unless you need to.

Setting the project compatibility

To create a new project in the Studio, you should select the compatibility based on the environment in which the project will be executed: 

  • Windows – Legacy: Uses .NET Framework 4.6.1. the compatibility used in releases prior to 2021.10. This is the default option.
  • Windows: Uses .NET 6 with Windows support.
  • Cross-platform: Uses .NET 6 with cross-platform support.

Designing cross-platform projects 

Cross-platform projects enable you to create automations that don’t require user interaction, including web browser automations using Chrome. Cross-platform automations can be executed on Windows and Unix-like operating systems such as Linux and macOS.

Linux environments allow you to run unattended automations and provide a faster experience and an easier way of scaling up your deployment. When using Linux environments, use Linux robots to run unattended automations. When creating an automation, make sure to select Cross-platform compatibility.


Storing and reusing components in separate projects is done through process libraries. A process library is a package that contains multiple reusable components, which consist of one or more workflows that act as individual activities. Libraries are saved as .nupkg files and then installed in different projects using the Package Manager.

How do we identify if a part of a project is reusable? Consider what sequences of activities can be used in several processes. For example: login, logout, starting multiple applications common to several processes, and data entry sequences.

Best Practices – Libraries

In libraries, each workflow can be set as public or private. Public items can be used as activities in projects where the libraries are added, while private ones can be used only inside the libraries.

Exception Handling

It is common for automation projects to encounter events that interrupt or interfere with the projected execution. Some of these are identified in the development and testing phases, and handling mechanisms are implemented.

Consider an automation where the input data comes from a web form, and the application tries to match the data with the list of existing clients using the last name. But what if the user makes a mistake when spelling the name? Naturally, the name won’t be recognized.

A good project design will include ways of recognizing and identifying the exception, and also patterns of action that are executed only when exceptions are caught. These can be simply stopping the execution, explicit actions executed automatically within the workflow, or even escalating the issue to a human operator.

Predicting and treating exceptions can be done in two ways:

  • At the activity level, using Try/Catch blocks or Retry Scope.
  • At a global level, using the Global Exception Handler.

The categories of exceptions are:

Application exception: The Application Exception describes an error rooted in a technical issue, such as an application that is not responding. 

Consider a project extracting phone numbers from an employee database and inserting them into a financial application. If, when the transaction is attempted, the financial application freezes, the Robot cannot find the field where it should insert the phone number, and eventually throws an error. These kinds of issues have a chance of being solved simply by retrying the transaction, as the application can unfreeze. 

In managing application exceptions, it is extremely important to have good naming conventions for activities and workflows. This will help with tracking the activity that caused the exception.

Business rule exception: The Business Exception describes an error rooted in the fact that certain data that the automation project depends on is incomplete, missing, outside of set boundaries (like trying to extract more from the ATM than the daily limit) or does not pass other data validation criteria (like an invoice amount containing letters). Business Rule Exceptions do not occur “naturally”, they need to be defined using a Throw activity. 

Consider a robot that processes invoices, with a business rule set by the process owner that only invoices with the amount below $1000 must enter the automated process. For the others, a different flow is applicable, involving a human user to process them.

In this case, retrying the transaction does not yield any chance of solving the issue, instead, the business user should be notified about the pending invoice and the case should be treated as a business exception – because is an exception from the usual process flow and the validation is made explicitly by the developer inside the workflow. 

As a recommended practice, the text in the exception should contain enough information for a human user (business user or developer) to understand what happened and what actions need to be taken. 

Version Control Systems Integration

Source control systems are particularly useful in larger projects, where multiple teams and individuals contribute in each stage. Source control systems allow users in different teams and locations to access the same resources and work on the same project. They are also used for versioning the code and maintaining the history of all the changes made during development.

Through the Teams page in the backstage view, Studio supports the following source control systems:


With the Git integration you can:

  • Clone a remote repository.
  • Add a project.
  • Commit and push.
  • Copy a project to Git.
  • Create and manage branches.
  • Solve conflicts with File Diff option.


  • The following versions are supported:
    • 2012
    • 2013
    • 2015
    • Express 2012
    • Express 2013
    • Express 2015
  • First, you need to setup TFS in Studio.
  • Then you can open a project or add a new project to the TFS.


With the SVN integration you can:

  • Open a project from SVN.
  • Add a project to SVN.

Best Practices

Design before building: Analyze the process thoroughly, identify the requirements and plan what the solution should look like before starting the actual development.

Use Remove Unused button: Remove unused Workflows, Variables, Arguments, Dependencies, Imports, Screenshots before publishing the project.

Break the process down into components: Break the process down into smaller workflows for a better understanding of the code, independent testing, and reusability. This can also impact the effectiveness, as different team members can work on different (smaller) workflows.

Reuse components: Use libraries for creating and storing reusable components for your projects.

Use folders in your project: Group the workflows of your project into different folders based on the target application.

Follow a naming convention: Keep a consistent naming convention across the project.

Configure arguments correctly: Use the right type of argument (In/Out/InOut) when invoking a workflow based on the direction of information. For naming, our recommendation is PascalCase with the direction of the argument as a prefix (in_/out_/io_).

Handle sensitive data with care: Handle sensitive data responsibly: no credentials should be stored in the workflow directly, but rather loaded from safer places like the Windows credential store or Orchestrator assets and used with the Get Secure Credentials, Get Credentials and Type Secure Text activities.

Handle specific exceptions: Use Try/Catch blocks to predict and handle exceptions. At the same time, remember that simply using Try/Catch will only identify the error, not solve it. Thus, make sure you develop error handling mechanisms and integrate them.

Handle global exceptions: Use the Global Exception Handler for situations that are global and/or less probable to happen (for example, a Windows Update pop-up).

Make your projects easy to read: Add annotations to your workflows to clarify the purpose of each workflow.

Use logging: Use logs in production to get relevant information regarding critical moments or anytime specific data is needed.

Use the Workflow Analyzer: Before sending your project to peer review, run the Workflow Analyzer to see how compliant it is with the development rules defined by UiPath and your organization.


Available options for publishing project templates: Orchestrator Tenant Libraries Feed, Local and Custom.

We are automating a banking process that moves money from clients’ accounts according to certain rules. It makes payments, it calculates interest rates and, each morning, it moves the amounts of money according to specific rules. The process is continuous. 

What is the best workflow to use? Answer: State Machine

What are the principles an UiPath implementation should follow?

Answer: Efficient, Maintainable, Extensible, and Reliable.

Which variable type is fit for datasets of single values whose number is liable to change?

Answer: List

Which factors should be considered as criteria for breaking down a project into different workflows?


  • Having sets of activities serving different purposes in the same project.
  • Using more than one application


Diploma of completion
Diploma of completion