That is absolutly no solution, beause of the following conditions:
A: The separation in Tenants separates not only user, but also machines and packages (even if you yould work around with external storage etc.) and I can not manage items from several tenants at once. This leads to huge maintenance and administration costs if you scale it up.
B: The separation in OrgUnits is very usefull, considering that i can attache users to n>=1 OrgUnits on the fly. But there is only one level of OrgUnits. The disadvantage comes, when you scale it up and have a person, that is the administrator of its local machines or servers connected to Orchestrator, but should only be a user in other OrgUnits. How can you do that, considering that with AcitveDirectory every user has only one account.
C: Environments do not separate users. Therefor it is no separation at all.
Summarizing that I have only one level of separation is the reason why there is no solution. I can not build up a hierachie in this setup. I can of course separate the administrators from developers and users by role, but that does not bring the solution I need.
Let me give you some backgroud, why I need to separate hierachies on two simple examples:
1 - regional/national characteristics
We use UiPath in an worldwide setup. You find regional conditions, that are unique in the community, like software copyrights or software distribution laws. On top of that you have local business software, perhaps a workers council you need to inbound, and many other characteristics, that should be able to be separated somehow. In some regions you are not allowed to communicate with encrypted emails (algier) and so on…
2 - teams
A team has a head in most cases. Due to having only level of users, how can there be a teamhead. And role only defines WHAT you can do. The OrgUnit defines WHERE you can do. It is not even possible to have a team in an OrgUnit that share a common Environment and have indiviuell Environments, because from my understanding I can set the role (rights to view, create, edit or delete Environments) only on or off. And than you have this right inside the OrgUnit you are assigned to.
–> That leads to the conclusion that I need a separate OrgUnit for every item I want to have separated. That makes the number of OrgUnits to big to handle in an appropriate condition.
3 - hierarchie
In the real world in an enterprise there is allways a hierachie. Even UiPath has a hierarchie for its own team.
I work for a big company and we plan to roll out UiPath in a very big scale. In the current days we try to find naming conventions, that help us to handle only a few teams in a few countries. It is a nightmare to plan with only one level of user separation.
For me i can not understand why it would be a problem to introduce some levels to the OrgUnits. So that I have OgrUnit 1, 2, 3 and 1.1, 1.2, 1.2.1 for example. Than I could assign a user to OrgUnit 2.2 (Germany) and he would autmatically be assigned in all OrgUnits 2.2.X.
Can’t be that hard…