Before we start: Orchestrator is the heart of UiPath’s automation management, it is the web-based provisioning, monitoring and controlling element within the tool’s infrastructure. If one thinks in terms of music, Orchestrator can be thought of as the conductor controlling the whole orchestra of musicians – the robots in this case – who are carefully playing each note from their sheets in front of them –the robots executing individual steps in the processes. Thus, the question can be rephrased the following way: should we have a single conductor leading our band of robots - company-wide - or should we each have different conductors and hence different orchestras.

Below image shows the user interface of Orchestrator for UiPath Studio Community edition. (Source: UiPath RPA Academy)

Pros for a single company-wide orchestrator:

 - Maintaining multiple orchestrators is a luxury, especially in current times: yearly licences, infrastructure costs such as servers, databases and maintenance costs add up a single orchestrator is more economical.

 - A single orchestrator allows for a companywide version and thus better quality control: process standards, naming conventions, framework adherence, information security considerations, package versions etc. These are all centralised: quality is ensured.

 - There is no issue with Orchestrator version lag: some parts of the company are keen to update as soon as it is available, others are more reluctant and will wait till the last second. Version lag can hinder the synching of companywide policies with regards to access rights or standardising in general: versions may not be backward compatible (especially older Orchestrators) and will certainly not contain the same functionality.

 - If all robots adhere to the same standard and are developed with the same package versions, it is easier to reuse their components, which could speed up development and reduce cost.

Cons for a single company-wide orchestrator:

 - Security issue: opening such a “tunnel” between countries could be problematic from an information security perspective.

 - RPA teams and RPA process numbers tend to grow faster without a controlling body above them: considering the rapid nature and general aim of RPA, hindering its growth is seriously disadvantageous.

 - Convenience: an RPA team with their own orchestrator, not having to wait for any third party is undeniably more convenient than any other setup.

 - The question of ‘who will move?’: if multiple teams have already started off with their own Orchestrators, it will always be a difficult discussion to decide who will move in with who.

 1. Teams with less robots should move? – the idea that those with less furniture should be the ones who move.

 2. All subsidiaries should move in with the team from the parent company? – the idea that the parent company should be the one in control of the Orchestrator.

 3. All should move in with those who started first? – the idea that those who pioneered the technology within the group should be the one in control.

There are no two clients who are identical : everyone should consider their own circumstances, consult with their teams and weigh their own company-specific pros and cons. In our experience, there is no right or wrong approach:

 - For one of our clients a single orchestrator controls all robot colleagues in 4 different countries – cost and version control aspects triumphed over other considerations.

 - For another one of our clients each RPA team got to keep their Orchestrators arguments from an agile perspective and the desire for speed were just too strong

However, in general: the earlier the decision is made the better. “Which one will it be for your company? One or many?”