OK thanks for the explanation. However I'm sorry that vRO is designed like this.
There are a practically infinite number of things that someone that manages a VMware environment might want to do represented in Orchestrator. So many that attempting to define all them in the permission of a separate front end tool is impractical.
In a large VMware environment with a large number of people performing VMware administrative functions, not everyone can be a full admin in vCenter - that would be a terrible security practice. And they can't be given access to a tool that bypasses the security in vCenter by allowing "share a unique session". Also creating permissions around every individual workflow in vRO is obviously impractical.
If in vCenter a company is following the principle of least privilege and assigning roles to groups, rather than individual permissions to users, which is a security best practice, it doesn't make sense not to have that ability in vRO. The front end would be a good solution when my target for that it a group of sales people that all need to log in and run a workflow that emails them how many VMs their customer has in their vCenter folder.
But Why would I not want to be able to map the same roles and levels of permissions that I have in vCenter in vRO and allow admins that use the VMware environment to create scheduled, orchestrated workflows and use vRO features to automate the tasks they would normally do manually in vCenter, keeping the same permissions as vCenter, and doing it in a centralized manner such as with multi-node?
I can see a use for the web front end but it seems that design doesn't universally fit all scenarios, and I can't see a reason not to have a roles / groups construct in the client for those that could use it.
thanks for the explanation though!