Use of UiPath Orchestrator Folder Packages and Workspaces

Learn Video Tutorials
, ,
1

Have you ever thought of organizing and separating the packages and processes you develop & test from the packages in production in the UiPath Orchestrator instance?

Until now, we had only one place to list all the Packages in production, development, and testing environments if you have only one Orchestrator instance.

With the latest release V 20.10, now we have the ability to create Package Feeds for Modern folders where you can convert the folder to a personal/ team workspace separated from other processes and packages to continue your work without affecting existing processes.

Check out the video to learn how to organize and maintain your packages using Package Feeds and Modern Folders to work in separate workspaces.

1 Like
2

Hello @Lahiru.Fernando,

Great video, I believe the Modern Folders are underrated. I don’t hear many people speaking about them, but they have a huge impact on the organization/division of environments within the UiPah Orchestrator.

Let me ask you something, a few months ago you posted your opinion on another post regarding the division of environments (test, dev, prod)
Reference: Suggest Recommended Approach for Dev,Test and Prod environment within same orchestrator instance - #3 by Lahiru.Fernando

After the release of the Orchestrator 20.10, do you still think the best approach is to have separate Orchestrator instances, or does it make more sense to have one Orchestrator instance with separate modern folders: Development, Production (each one with separate Assets, Queues, Processes, Permissions, etc…)? If not, why?

I appreciate your thoughts on this.

Best regards,
Gil

2 Likes
3

Hello @Gil_Silva

Thank you so much for the comment. and I agree with you regarding modern folders. I have the same experience when it comes to these, as many do not either use, or do not really know the impact it can bring in to organizing and managing automations.

Regarding the question:
Going back to the same post, I would still stick with the answer I gave previously, which is to have separate Orchestrator instances for Dev, Test, and Prod.

I know, the features the modern folders have now, we could do the same thing in the same instance. But, when it comes to environment management, there are few things that we need to think…

  1. How we are to manage updates
  2. Disaster recovery
  3. Separation from development
    – there could be many more…

When it comes to development environments, usually things are messy. We change many things time to time, configure stuff, upload and test processes, delete… (basically we do everything possible)

In production, we need to have proper control, and less involvement from different people unless its really needed.

We could do this in the same instance using modern folders… Agree… but, when it comes to system updates, if we are to upgrade the Orchestrator version, we are affecting all three environments at the same time. And this may end up with consequences that we wouldn’t even know and take time to resolve.

So its always safe to have separate instances for different environments like dev, test and prod.

However, this is also depending on the budget… :slight_smile:

To add more, I do really recommend using modern folders and its features to properly organize and separate the automation solutions we have between different organizational units…
Also with the latest feature that enables to publish packages to different folders, really help people to organize the solutions and make them more secure and specific.

2 Likes
4

Hi, sorry for reviving this old topic.
We are currently in the process/evaluation of migrating to Modern Folders. Your video was very helpful to understand how folder level package feeds work.

However one thing were I am still trying to figure out on how to achieve it is proper segregation of assets without having to change the config file or the project each time we set a project live.

So the gerneral idea is to have 2 seperate top level modern folders, one for DEV and one for PRD. Developers only get access to the DEV folder, PRD is restricted to monitoring only and for setting the projects to production by very few people.

Since we do not want our developers to access PRD systems we would like to only maintain URLs and Credentials for development systems in the assets of the DEV folder. But: How can we redirect the executor to use the PRD asset once the package is published in production level without having to change the Value “Orchestrator Folder” in the Config.xlsx and the Get Credential activities.

My idea is that the process automatically gets the assets from the folders its been started in. If its started from within the DEV folder it will take the DEV assets. If its started from the PRD folder it will take the PRD assets. Is that possible to achieve and if so is there a best practice for it?

Best regards
Tim