I want to validate the use of these default roles based on two differing primary sources:
These have different roles such as enable running automations and allow to be automation user. These roles almost look the same. Was this a hidden fix of what the roles should have been and which should I use?
I think the Allow to Be… is more right but the documentation is confusing. The articles should line up together unless someone can explain why there is a nuance.
In latest versions of orchestrator, you should be able to see standard roles availability which you can just enable and use.
For this, go to tenant-> settings-> scroll down, you will see roles section as below
Yes, I have done the same. Except that the old roles from V19 still are there. I’ll need to remove them and reassign those users to the newer versions of those roles.
I think we resolved this topic by removing the duplicitous role. Modifying a deprecated role doesn’t seem practical. We kept the newer auto-generated role in the new Orchestrator and removed the old roles. I’m just trying to highlight for users who upgrade their orchestrator why there may be confusion with two similar roles generated by Orchestrator.
Even for upgrades, roles are not enabled automatically unless done specifically from settings menu.
And once enabled from there, they can also follow the process of removing duplicate roles or may be can go for modifying existing ones itself without utilizing new available roles.
So it really depends on how an org wants to move ahead with role defining/refining process.