Org Unit or Environment based Roles

Feedback Orchestrator
,
1

Currently, we are using 1 orchestrator environment with multiple tenants, org units, and environment. One of the issue we had was granting appropriate privilege on the different org unit and environment, due to how we are being set up.

The role based permissions currently applies across the tenant, not to the org unit (unless we do not grant them permission to that tenant). We use do have use cases such as certain roles requiring to create or update packages in 1 org unit or environment but not the other.

2

So the problem is that User A having Role B will get the same role in Unit1 and Unit2. You can not have the same user having RoleB in Unit1 and RoleC in Unit2. Right?

1 Like
3

That is one part of the problem. If you have a role, it is tenant wide role in all orgunits you are assigned.

The second and much bigger problem is the missing inheritance. Both in OrgUnits itself and in the roles.

For example. If you build a big department all units are on the same level. This is not the reality in most cases.

Please bring up a solution, so I can manage bigger company structures appropriate

4

How many levels do you need?

5

3 or 4 would be great! If you can make that happen I would work out the exact number. But if you would implement something like that, would it not be n-levels?

I thought about an inheriting structure, where I can create an OrgUnit and place it as a child into the parental OrgUnit. So the user from the parental OrgUnit have the rights in all child Units, but not vice versa.

6

That’s right Mihai

7

Inheritance is a mixed bag, best to keep it simple or box it around a scope. Once you start requesting for breaking of inheritance, it becomes unmanageable.

How about roles that are defined at the orchestrator level which you can reuse/inherit across tenants or orgunits. and then just 3 levels, tenant, org unit, environment.

8

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…

1 Like
9

Hi @alienz @fraydex

Please let us know if the newly introduced Folders fulfil your requirements :slight_smile:

10

Hi there, in a way, yes :blush: more than what I’ve asked for, but also mean more setup / potential to get messy in future. However this is a flexible implementation, and thanks for getting this out. :+1: