Questions about UiPath architecture: Shared Libraries, Scheduling, Git, Orchestrator, and Version Management

Help Automation Ops
1

Hi everyone,

I recently started working in a UiPath environment and I am currently reviewing how our RPA projects are structured and operated.

I have a few questions about common practices and best practices in UiPath. I would really appreciate hearing how other teams manage these areas.

I realize this is quite a long list of questions, so I would sincerely appreciate any advice or experience you can share, even if you are only able to answer one of them.

1. Sharing common libraries when Orchestrator Organizations are separated

We are planning to create a common library containing reusable workflows such as login, file handling, Excel utilities, browser handling, credential handling, etc.

However, our Orchestrator environments/Organizations are separated by project or bot.

What would be the recommended way to share the same common library across these separated environments?

For example, would you normally use:

  • a shared/custom NuGet feed,
  • a shared network folder,
  • or publish the same library package separately to each Orchestrator environment?

In our environment, we generally have one bot/PC per RPA project.

If the common library is updated from version 1.0.0 to 1.0.1, do we normally need to update the library dependency in each individual RPA project, test it, and republish each project?

Or is there a more efficient/common way to manage library updates across many bots and projects?

2. Using Windows Task Scheduler instead of Orchestrator schedules

I noticed that some RPA processes are executed using Windows Task Scheduler rather than Orchestrator triggers/schedules.

Is this a common approach in UiPath production environments?

If you are using Windows Task Scheduler, what are the typical reasons for choosing this instead of using an Unattended Robot with Orchestrator scheduling?

For example:

  • licensing or cost,
  • infrastructure limitations,
  • security restrictions,
  • legacy architecture,
  • or other reasons?

I am curious whether this is considered a normal production architecture or more of a workaround depending on the environment.

3. Common/reusable modules used by other UiPath teams

Do most UiPath teams create and maintain their own common libraries?

If so, what kinds of reusable workflows or activities do you usually include?

For example:



Common Library
โ”œโ”€ Login / Logout
โ”œโ”€ Create Task Folders
โ”œโ”€ File Exists / Wait for File
โ”œโ”€ File Backup
โ”œโ”€ Excel validation
โ”œโ”€ Browser / Application cleanup
โ”œโ”€ Mail handling
โ”œโ”€ Credential handling
โ”œโ”€ Logging
โ””โ”€ Exception handling utilities

Are there any commonly used design patterns or recommended structures for building a reusable UiPath library?

If anyone has sample projects, GitHub repositories, example workflows, or documentation showing a good common-library structure, I would really appreciate it.

4. Git branches and Orchestrator package management

Our Git repository currently has a development branch and a main branch.

Is it generally okay for developers to commit/push directly to the main branch?

Or is a flow like this more common?



Development branch
        โ†“
Review / Test
        โ†“
Merge
        โ†“
Main branch
        โ†“
Publish UiPath package
        โ†“
Orchestrator

Also, when using both Git and Orchestrator, how do you normally divide their responsibilities?

My current understanding is:



Git
โ†’ source code version control
โ†’ XAML / project.json / configuration files
โ†’ development history

Orchestrator
โ†’ published packages
โ†’ deployment
โ†’ execution
โ†’ logs / monitoring

Do most teams use both Git and Orchestrator together, rather than choosing one or the other?

How do you normally link a Git version/commit/tag with a published UiPath package version so that it is easy to trace what source code is running in production?

5. UiPath / Windows version standardization and upgrade timing

Another issue I noticed is that the environment is not fully standardized.

Different bots/projects may currently be using different versions of:

  • Windows,
  • UiPath Studio / Robot,
  • activity packages,
  • browser versions,
  • browser extensions,
  • and common libraries.

For example, one bot may be running on Windows 10 with an older UiPath version, while another may be running on Windows 11 with a newer version.

Is it common to allow different bots to remain on different UiPath/Windows versions as long as they are stable?

Or do most teams try to standardize the environments across all bots?

Also, how do you normally decide when to upgrade UiPath Studio/Robot or Windows?

For example, do you upgrade:

  • whenever a new version is released,
  • only when the current version is close to end of support,
  • on a fixed yearly schedule,
  • when there is a security requirement,
  • or only when a specific project requires it?

When performing a major environment change, such as:



Windows 10 โ†’ Windows 11

UiPath 2023.x
      โ†“
UiPath 2024.x / 2025.x

what kind of validation process do you normally follow before changing production bots?

Do you maintain a separate test machine/VDI and run regression tests for existing automations before upgrading the production environment?

I would also be interested to know whether teams usually define a standard combination such as:



Standard RPA Environment

Windows version
UiPath Studio / Robot version
UI Automation package version
Excel package version
Browser version / extension
Common Library version

and periodically migrate all bots to that standard.

I would appreciate any advice, examples, or experiences from teams operating UiPath at scale.

Thank you!

2

Hello,

Great questions.

  1. Definitely use libraries but dont make the mistake of putting all you list in a single library.
    If you are doing a library to log into an application for example, that should be a distinct library from one doing Excel file handling or something. Make them small, focused and testable. Each application you use should have a separate library.

As for sharing them. Its a good setup to use the library package feed and deploy it that way, it helps ensure you are deliberate in what you move to the prod tenant, rather than letting untested versions on the library leak into prod. If a library is missing the job will fail and not start with a clear message.

One bot per PC per RPA project is wild to me. Thats a huge licencing cost for a single project, you can run lots on the same machine and its worth using the robot runtime alot more than that.

  1. The task scheduler is not supported by UiPath and shouldnt be used.
    Typically I find its associated with breaking the licence usage terms, where someone wants to use an attended robot, in an unattended fashion. If this is the case, stop it immediately. You need to pay the appropriate price for the unattended licence, and not force the cheaper attended licence in this manner.

  2. For common libraries, I canโ€™t speak for all teams, but Iโ€™ll share some of mine.

  • One for helping render complex emails in a nice way using the Razor template format.
  • One for helping encrypt and decrypt data used in a transaction
  • One used in the version of the REFramework (re-built entirely) where certain tasks to that are done via the library to make the project leaner.
  • One used to display the logs on the screen during a robot execution, useful for attended or unattended runs so you can see whats happening when Studio isnt running.
  • One used to help build URLs to items in the orchestrator. For example to the logs of a job, or to a queue item, making it easy to include direct links in exception reports.

Things like mail handling I prefer to leave it implemented per project, partly because libraries donโ€™t support integration service activitives and thats a preferred email route. Its also easy enough to have a workflow in the project dedicated to sending mails etc, and other stuff is more per project logic.

As I mentioned above, any application gets its own library.

  1. The answer here depends on your pipelines to be honest. If you have no pipelines you donโ€™t really need the development branch, all it will do is increase the chance of someone working on the wrong branch and since UiPath development usually doesnโ€™t have multiple developers on the same UiPath studio project, it doesnt need the additional GIT branches.

If you have pipelines though, that changes things.
I donโ€™t know what your review process is like, but its worth considering branches if you want to control it the way you do.

Donโ€™t take my comments above as saying โ€˜donโ€™t use branchesโ€™, my sentiment is โ€˜use branches, but get the value out of them by using pipelines tooโ€™.

I am not sure what you are asking regarding the divide between GIT and Orchestrator.

GIT is where you store your code, Orchestrator is where you run it?
If you are meaning should you get your code back out of Orchestrator, which I have seen some people do, thats terrible practice, especially since the packaged version can convert dependencies to runtime versions aswell as removes things like screenshots.

  1. You should standardize. This sounds like a weird mess. You should also check what versions of UiPath they all are and ensure they are in support.
    You should ask if there is a reason some are stuck on old versions.

4

Thank you for your response! 1. If the organizations are different in the orchestrator, can I create a library and save it in a company shared folder for use?

  1. Can you tell me how to see what happens when the Studio is not running, whether there are people present or not?

  2. There is no separate pipeline. Iโ€™m mainly curious about where you usually save the main.xaml source file.

5

Its abit unusual for the organizations to be different? Can you share the reason for that?

I would recommend against using a company shared drive as nuget package folder source. I would stick to the standard source types and use the Orchestrator feed.

  1. You can live stream an unattended job from the Orchestrator, or you can turn on job recordings for faulted jobs.
    It is also possible to log in to a machine during an unattended execution, but I recommend against it as it can interrupt some robot actions.

  2. I am not sure I understand you, where you save the Main.xaml file doesnt seem relevant. Its part of the project, and the entire project goes in GIT. I would never see or understand why youโ€™d want to store a single xaml file separate from the project?

Also. I see that you are writing in Korean and the forums are automatically translating to English for me. Its possible that some of the things we say get translated slightly incorrectly. Hope none of my messages are misunderstood, Iโ€™ll do my best to understand you well also.

6

I donโ€™t understand why the organizations are different here. We use an Attended Bot here, and we log in to different organizations depending on the assignment category. It looks as if they are not being shared with each other, so creating a sharing task is in a confusing state.

  1. If I also want to register the Attended bot in the orchestrator for monitoring, will I need to make an additional purchase?

  2. I spoke incorrectly. I meant the entire package file, not the main file. Then Iโ€™ll understand it as uploading the entire package to Git, and then uploading the executable file in the orchestrator!

Thank you for understanding the language!
It is providing a lot of help in this confusing situation. May you be blessed with all things good.

7

It smells fishy if you ask me (hope that saying translates well), and especially on the new licencing plans with the platform costs it would balloon the price massively.

What licence plans are each of the organizations on?

Regarding GIT, its for the source code, its NOT for the packaged code. When you build the package you upload it to a nuget feed, usually the one in the Orchestrator.

8

It seems to be an Attended Bot license .
Do the prices of Attended Bots and unAttended Bots differ a lot?? I canโ€™t know the price..The bot isnโ€™t connected to the orchestrator, so itโ€™s not being used for execution.. so The source code is development code, and the package is executable file, right? Iโ€™m confused about uploading twiceโ€ฆ (the orchestrator and the git)

9

Sorry, I missed the response.

The cost does differ alot. Its $2,000 attended and $10,000 unattended.
Running it outside of the Orchestrator as an executable is another red flag to me.

These are all the actions people take when they try to deliberately avoid paying any licence fees and use UiPath illegally. I donโ€™t have enough to say thats for sure whats happening here, but it sounds very very fishy and if I were in your shoes I would register some concerns here and require the previous people to defend their conduct.

That being said, the licence term for the free community version have now changed. If the company has annual revenue lower than 5 million USD then you can use Community for free commercially, otherwise I think something is up.