Program organization

On a high level, there are different ways to organize the UiPath RPA program to build for scale. Various organizations deploy different strategies based on agreed policies.

In this section, let’s talk about two strategies to define a UiPath program organization. Program sponsors and architects usually characterize them, but UiPath support and Administrator teams should also be consulted when designing the structure. The UiPath Administration team will be the responsible party for the actual set of this model in UiPath environments.

We will use the ABC Insurance Corporation's UiPath RPA program as a reference to explain the concept better.

Organizing tenants and folders

When we install UiPath Orchestrator to an on-prem or set up on the cloud, we will get a Default tenant visible when we log in for the first time. Every organization starts with one tenant for the proof of concept and pilot. Once they get requirements, they mature and organize the UiPath resources in a multi-tenant environment.

It is essential to understand the meaning of the terms and their significance:

• Tenant: This is the highest level of grouping UiPath Orchestrator resources such as Robots, processes, machines, and so on. It is always recommended to have multiple tenants, usually at the organization function level such as finance and HR. You can log in to Orchestrator and learn more by viewing how the context changes:

Figure 1.13 – Tenant setup

• Folders: This is the next level of grouping resources such as processes, assets, and so on, and it is usually at the business process level. The Robot’s and user’s rights can be defined at the individual folder level or inherited from the Level 1 folder. IT service management is a good example of a folder that will contain processes such as incident management, problem management, and so on, that is, UiPath Service Now integrations jobs. Modern folders are used in ABC Insurance Corporations’ UiPath setup.

Note

We can add a subfolder as well to have more control at the subprocess level.

Figure 1.14 – Folders setup

Note

We have one more segregation called Environment supported in classic folder setups only, and it is very similar to the subfolder concept. We can group Robots and processes to dedicate them to a partial environment.

Figure 1.15 – ABC Insurance tenant/folder structure example

This was how the ABC Insurance UiPath program was organized, and there are many other approaches to manage the Robots, jobs, and other assets. The principal rule in many firms is that the team that pays for the license decides the strategy.

Organizing the RPA environments

The next level of organization is to replicate the above tenant/folder (along with all the resources) structure in different environments, namely test, User Acceptance Testing (UAT), and production.

The ABC Insurance Corporation’s UiPath program setup is depicted in the following diagram; let’s discuss the concept in detail:

Figure 1.16 – ABC Insurance Corporation’s UiPath environments

The details of the four environments depicted in the diagram are explained in the following sections, lets start with the development environment.

• Development environment: This is the primary environment where ABC Insurance Corporation’s UiPath developers use Studio/Studio Pro or Studio X to create the automation. Ideally, individual developers will have separate licenses allocated to them. The Studios are usually connected to the UiPath test Orchestrator node. The developers also perform unit testing in this environment; then, the packages can be published in the test Orchestrator once the connection is established.
• Testing environment: This is the primary environment where ABC Insurance Corporations UiPath testers perform their system and integration tests. The UiPath test Orchestrator (non-production license type) and non-production Robot are usually configured in this environment. The tenant/folder setup and access rights for different UiPath resources need to sync in the test/UAT and production environment. The jobs that are created from the package from the Studio can be trigged in the test environment. Multiple test bots can be configured to perform the test as per the business need. The testers will usually use this environment to run functional, integration, performance, and security tests.

The test environment access for the target application(s), such as Salesforce and Mainframe, needs to be provided to the bots in this UiPath environment to perform the tests.

Note

If you use the UiPath Test Automation Suite, then testing Robot licenses are needed to execute the test automation.

• UAT environment: This is the primary environment where ABC Insurance Corporation’s UiPath business users and user acceptance testers perform UAT. Once the package passes the test gateway, the same package can be uploaded to the UAT environment. This environment again has a non-production license Orchestrator and non-production Robots configured. The setup should ideally reflect the production environment as the test will be equivalent to dry runs in production.

The UAT environment access for the target application(s) that are automated such as SAP, Salesforce, and Mainframe, needs to be provided to the bots in this UiPath environment to perform the UAT tests.

This environment will be used by the business analysts/product owner, who will provide the UAT signoff. Once the UAT signoff is provided, the package will be promoted to the production orchestrator.

• Production environment: This is the primary environment where ABC Insurance Corporation’s UiPath business validators provide final validation and where the bots will execute the business transactions. This environment is the final runtime environment for the bots. This will have a production Orchestrator setup (single/multi-node), and production licensed Robots (unattended/attended) on VMs or servers. The automation packages that business stakeholders signed off on will be run in this environment.

The production environment access for the target application (automated, such as SAP, Salesforce, and Mainframe) needs to be provided to the bots executing the process in this UiPath production environment to perform the actual business transactions and processes.

Note

Based on the maturity of the UiPath programs, one or more of the environments may be missing in your current setup.

If the production is a multi-node Orchestrator setup, it is recommended that both test and UAT are multi-node setups. Risk reduction during Orchestrator upgrade is the primary reason behind this recommendation. The test and UAT UiPath Orchestrator nodes will be upgraded to a newer version before the production orchestrator is upgraded. The issues can be identified upfront and will improve the success rate of the production upgrade.

We mentioned the manual movement of the UiPath NuGet packages between environments by the ABC Insurance Corporation’s RPA team. It doesn’t always have to start that way, and the whole deployment process can be automated from the start of the program. Automated package movement through a DevOps pipeline has an extensive list of benefits to the UiPath RPA program. We will look at this UiPath DevOps concept in a later chapter.