I’ve looked through all available Orchestrator documentation & a number of forums. For the launch of an RPA program, we are trying to get a recommended role matrix. Ex: A developer should have View permissions for Machines, Robots, Processes, etc, Edit for x, y and z and so on and so forth.
In all of the documentation, there is not a description for each permission field and what is covered by the permission area. I’ve also not found any best practice recommendations on the roles you should set up and with what permissions.
I know competitor’s like Blue Prism provide a Logical Access Model that describes each permission component as well as their recommended roles with associated permissions.
Does anyone have a description of each permission area and what it covers? And/or, are there “best practices” or role configurations you recommend from your experience?
Hi. Good question. Can you provide which version you are on, because I know that the newer version went through some good changes to permissions that could impact your outlook.
From my perspective (and I’m looking at v2018.2.3), the permissions are all straight forward. Each row is indicated by a section of the Orchestrator, like “Settings”, “Robots”, “Processes”, and so on, and each of those sections represent a button that is clicked to enter that section - so, if you want to restrict access to the “Audit” section there is a button that is used to enter that section, for example.
And, “View” “Edit” “Create” and “Delete” are straight foward as well. “Edit” means you can’t change a value, et cetera.
I think the best practice is somewhat subjective, but I do think you should keep it simple. I also do think you should have more than one administrator and one who understands the features good. Also, bare in mind that if the Role has “Users” “Edit” access, they would be able to change their Role. - atleast in older versions. You will want a Developer Role which will need Edit and Create/Delete permissions for most things to be honest. Then, you will need a Robot Role which is used for your robots, and they will also need Edit and Create/Delete access to many things (like Assets) so they can automate tasks in Orchestrator. If you will be having Managers or other Users use Orchestrator then you would need a Role so they can edit Assets or various other things.
Note: the new versions make User profiles more manageable from my understanding.
I would show a snippet of our Roles, but to be honest, I don’t think they are very good yet so don’t want to feed in bad information.
Clayton–thanks for your help on this! That makes a lot of sense to me. Version is 2018.3, but this is all pre-implementation work, so 2018.4 is also being considered.
Agreed on the settings being straightforward. From a documentation perspective, having the “functionality” of each permission explained helps from an audit and controls perspective by having “official” definitions. I think we are just going to use definitions from the Orchestrator guide and other material to ensure that each section is explained and makes sense.
And appreciate the view on the roles to have. That lines up with a role model we were looking at, keeping in mind change management controls and thinking about the concept of Segregation of Duties in Orchestrator. Our rough role model was similar to the Blue Prism…
Developer
Release Manager
Scheduler
Process Controller
Support Analyst
Manager
Audit [View Only]
That’s the rough sketch and we are still trying to work out the other roles and the permissions each needs.
Interested if others have thoughts in the community.
I also would be very interested in the roles mentioned above by @amphillips. Would be interested to know if anyone has some roles already developed as a starting point. We just installed orchestrator 2 days ago, so just getting the ball rolling.
Hi all,
I have exactly the same question as amphillips, and I’ve been looking for best practice recommendations on the roles to set up and permissions.
Considering Orchestrator usage in my Organization, my goal is to create only a ‘Developer’ role in addition to the default Admin and Robot roles. We have the default single tenant in Orchestrator 2018.4.1.
Our goal is that developers should be allowed to :
1.Upload new package
2.View process/ edit process-package version used
3.View Jobs
4.View Schedules
5.View Logs
6.View Queues
7.View Transactions
Current behavior is : Users with Developer role can View jobs/logs/transactions of other processes which are not developed by them. However, Is it possible to grant the View permissions(3 to 7) only on specific robot or within an environment?
We haven’t enabled OUs, the feature is mentioned as experimental. But even with OUs, to achieve the granularity we are looking for it would mean we run single Process within OU. That is not manageable.
@Amrita.Hegde, one thing we have been advising our clients to keep in mind are the change management controls. From a general IT controls perspective, you typically do not want your developers to be able to migrate their own code to production (due to the risk associated with it, such as developers moving untested code or modifying code after testing to production).
In helping set up roles with Orchestrator, I’m seeing my clients lean more towards having a role for the developer to be able to view, but not edit, create, or delete. Another role would be a change manager role that can upload packages, and create the processes and schedule (much like your developer role). Keeping Segregation of Duties in mind, the “Change Manager” is not going to be a developer. Again–this is going to all be dependent on the resources that you can train. One of my clients has a separate role for the “Code Migration” who simply has the create/edit package permission. This is to comply with internal controls that someone from the infrastructure team has to perform all code migrations to production environments.
Main point: make sure you check with your internal audit group that they are ok with the process (depending on your organization and size).
Happy to share an initial pass at an “Ideal List” of roles that I have been working on with a few others. We are still fleshing out this list, what permissions are baked into it, and what level of maturity you would see here.
Sponsor
Champion
Change Manager
Business Analyst
Solution Architect
Developer
Infrastructure Engineer
Supervisor
Service Support
Code Migration
Audit
Regarding your last point (setting up view permissions to only specific robots or environments), what are you looking to achieve? I agree that you couldn’t restrict “View Only” to just certain robots, but I’m not sure what end goal you are trying to achieve by doing that.
We have a Stage and Prod instance of Orchestrator, Robot nodes. Our idea is to create RPA Developer role only in Stage. The idea is to allow developers to validate usage of Orchestrator features-Queues,Assets, webhooks, unattended bots etc. Once they are production ready , the deployment to Prod environment will be performed by Administrators.
In the Stage infrastructure itself, we have multiple processes all developed by different teams, sometimes belonging to different lines of service. Developer role settings in my screenshot above, result in a scenario wherein Developer has access to view every log entry, schedule, job, etc.
Ideal scenario would be the one where, we could grant access based on process. All members associated with a process have view access only to the logs generated by their process. That way we don’t end up in irrelevant logs/assets being visible to all developers, these factors are important from Information Security and Compliance perspective.
I have a feeling that UiPath is working to improve that aspect. My thinking is you should be able set Roles to users to only be able to view/edit/create/delete processes that (for example) start with certain characters, or something along those lines. Like, if you have teams using prefixes for Processes, Assets, and etc they could only create/edit a process or asset with that prefix (ie “Team1_Process1”, “Team2_Process1”, and so on).
On the topic, I’m like the worst to ask about this, because I was once in IT, and they continue to move toward a compliance that “restricts” creativity and production efficiency. Also, there is an Audit log, so if someone was to do something dumb, we’ll know and give them a little slap on the wrist.
I think the answer to compliance should be more solved by technology (technology solving both technology and human stupidity) rather than just telling everyone (that does all the heavy-lifting work anyway) that they are just minions.
Anyway, you definitely need to open up View, Edit, Create, Delete for Robots, Assets, Queues, and Jobs… for robots and developers, because those things are interactive with your process (otherwise you can’t fully use the features as you make processes). There are many others to consider as well for developers.
I think all the “View” should be enabled so Orchestrator is more transparent, so the UiPath automation creators know what is going on.
