Is there a best practices for folders in orchestrator?
Or do anyone have experience with different setups? Bad? Good?
Planing to setting up a folder structure using modern folders and sub folders, divided by different organisational units.
It really depends on how you would want to organize folders in your organization.
Like some people would go for having different tenant - dev , uat for non-prod orchestrator and then having folders created in there corresponding to different org units.
Or some would go about having just 1 default tenant but creating folders in there corresponding to an org unit under which they would prefer going for creating sub folders for different environments.
It really depends on your requirement and the way you want to handle it.
Hi @viebke (André)
It is admirable that you are taking time to think about the consequence and it is very important to do this excercise.
Modern folders are exactly like a SharedDrive where individual folders have their own permissions policy. Only certain users can have admin rights to all folders and other get access to only their own folders. Both Modern folders and a SharedDrive will support AD integration so this makes brainstorming easy.
We sat down as a team and created nested folders and tested our use cases, we did this both in a shared drive and in our development orchestrator and answered a set of what-if questions:
For example (from what I can remember),
- What-if the robot needs access to assets and processes from another folder?
- What-if a process needs to be ported from one department to another?
- What-if the API user needs to be locked to one of the folders/departments due to security policies. What-if we expand from RPA to Test-Automation offerings?
- What-if we want to use a common robot accross folders/departments?
- What-if two departments want to merge in the future?
You have to evaluate how your organization is structured and how your RPA team wishes to implement and maintain robots.
In the end, we choose a project based folder structure as most of the projects will anyway have their own assets and processes (naturally avoiding duplication of assets and processes). It would make it easy for us to identify end users who need access to a given project folder. Our DevOps connection has its own API user and has access to all projects where the connection is required. Security wise, we known only us the RPA team has access to the Orchestrator/s and the DevOps organisation.
Hope this helps you and others.
Sorry for the late reply.