Title: Best Practices for Versioning and Managing Reusable Libraries Across Multiple UiPath Tenants

Help Studio
1

a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; }

Hi Everyone,

I have started initiating reusable components using UiPath Libraries in our RPA practice, and I am looking for guidance and best practices on library versioning and multi-tenant management.

I have a few questions and would really appreciate your inputs and thoughts:

1. Library Versioning and Impact on Existing Bots

  • If I publish a reusable library and later make changes in the code (bug fix or enhancement),
    • Should I update the library package version in all the processes where it is already being used?
    • Is there a best practice to avoid breaking existing automations when a new version is published?
  • What versioning strategy is recommended (Major / Minor / Patch) for reusable components?

2. Managing Reusable Libraries Across Multiple Tenants

I currently work with multiple UiPath tenants (Tenant A, B, C, D, E, F).

  • I want to maintain the same set of reusable libraries across all tenants
  • I do not want to publish the same library manually tenant by tenant
  • Is there a supported or recommended way to:
    • Publish libraries once and make them available across multiple tenants?
    • Use Automation Cloud feeds, shared feeds, or CI/CD pipelines for this purpose?

3. Best Practices Request

  • How do enterprise teams usually handle:
    • Centralized reusable components
    • Library governance
    • Cross-tenant reuse
  • Any recommended architecture or real-world implementation examples would be very helpful.

Thanks in advance for your guidance and support.
Looking forward to learning from the community!

Regards,
Vignesh

2

1. Library Versioning & Impact

The “golden rule” of libraries is that existing bots should not break when you publish a new version.

Versioning Strategy: SemVer

You should adopt Semantic Versioning (Major.Minor.Patch):

  • Patch (1.0.1): Bug fixes only. No changes to arguments. Safe to update across all bots.
  • Minor (1.1.0): New features or activities added to the library, but existing ones still work exactly the same. Safe to update.
  • Major (2.0.0): Breaking changes (e.g., renaming an argument, deleting an activity, or changing logic that alters the expected output). Requires manual testing before updating.

Best Practices to Avoid Breaking Bots

  • Do not update automatically: Bots should point to a specific version of a library (e.g., v1.2.4). You should only update the bot’s dependency in Studio when you are ready to test and redeploy.
  • Argument Persistence: Never delete or rename an Input/Output argument in a Minor or Patch update. If you need a new input, add it as an Optional argument so old bots continue to function without it.

2. Managing Libraries Across Multiple Tenants

Manually publishing to Tenants A through F is a “maintenance trap.” You have two professional options:

Option A: The “Shared Feed” (Automation Cloud)

In UiPath Automation Cloud, you can configure a Host Feed or a Custom External Feed (like ProGet or Azure Artifacts).

  1. Host Feed: Go to Tenant > Settings > Deployment. Set the Library Feed to “Host.” This allows all tenants to pull from a single, centralized library repository.
  2. External Feed: If your organization requires stricter security, you can use a private NuGet feed. You publish once to the feed, and all 6 tenants “subscribe” to it.

Option B: CI/CD Pipelines (The Pro Way)

  • Tooling: Use Azure DevOps or GitHub Actions.
  • Workflow: When you push code to your Library’s Git repository, the pipeline triggers. It builds the .nupkg and uses UiPath CLI or DevOps Tasks to deploy that single package to all 6 Orchestrator tenants simultaneously.
3

The thing to avoid is removing arguments or changing datatypes, since those will break the activities in the projects that use them because it will claim an argument cannot be found.
Now, that being said, if you need to change a data type to correct a bug or something, you shouldnt leave it in just to avoid that, sometimes there will be more painful updates. You can best avoid it with good design in the first place, you need to design your activities so you can easily extend them, without changing the core behaviour.

I completely disagree with the advice the GPT user gave above.

The major, minor and patch updates are basically pointless in libraries like this.
Adopt calendar versioning, the same that UiPath uses for most of its stuff now to avoid having your library at 1.0.57 or some other meaningless release number.

Instead have it 26.4.2 which indicates it was the second release in April 2026. It keeps the numbers smaller and makes them more meaningful / useful.

For sharing the libraries, you need to configure a private feed you can publish them to and then have that feed available to any robots on the machines you run your automations.
I tend to just publish my libraries to the appropriate tenants when I am ready for release. Pipelines can help with this if you set them up, but it does take work.

1 Like