Limit orchestrator access based on environments/robots/jobs


I would love to see more detailled permission settings based on environments or robots or jobs.

Use case 1) I want to enable a user to start jobs. There are multiple jobs available in his tenant/organization but he should only be able to start one specific job

Use case 2) There is one orchestrator with one tenant which has a staging environment and a production environment. The developers should only be able to do deployments to the staging environment and not to the production environment.

Use case 3) There are multiple robots within a specific HR environment. The user from use case 1 has to start a job in this environment but I only want him to start a job on a specific robot, since the other robots have to run on a important schedule. (if there were access rights based on environments I would also be fine with splitting these robots in two environments)


1 Like

I suggest access based on Robot Objects (i.e. all Reports, Logs, Jobs, Schedules, Assets related to given robots). With this, we can extend Orchestrator access to Business team to let them see status, reports, logs of their Robot execution. If passwords are being managed in assets, Business team can change password themselves or manage other assets.


Got an answer for the above use cases? I do have the same scenario if you could share it will be very useful.



Try to create Organsation units which ensure the separation of Orchestrator components within tenants for assigned users.

Hi raj,

This Organisation Unit setup is solving some of the cases but unfortunately not all of them.
For example as Thorsten mentioned in case 1: - You have to give access to a user to start only one process

you have one Org Unit with one environment with one robot with one process - case solved, however that robot is staked with that Org Unit and you can’t use it for other processes which is waste of resources.

The real approach would be to have the ability to allocate the Robot to multiple Org Units so you can share that resource with other processes.


Yeah, it’s a tough problem but, I think, for now it has a solution because a machine can be allocated to multiple units.

You may have
OU1 - R1(U1 - M1)
OU2 - R2(U2 - M1)
So the runtime is shared.

The problem is that a user with access only in OU1 will not be able to see what kept it’s runtime busy. But it is livable.

1 Like

Good post. I didn’t realise that the actual link is OU-ENV-Robot-Machine. As you said the robot can be associated with only one OU but the machine can be associated with any Robot from any OU.

Then question: If the runtime is a usual machine, and not a server with High-Density, then if one robot is running then the other one waits for the machine to be available or it will fail for not being able to login?

1 Like

Yes. It should wait (I hope :slight_smile: ) since 18.2. Before this was a problem even if the bots were in the same OU. The second would have crash. Now is set to pending and waits for the first to finish.