To add to @andrzej.kniola if it is possible to stop receiving commands for a particular robot on the Orchestrator as an option. Sometimes, the users do not have admin access to stop the service but if one can disconnect the robot for a while where that particular robot cannot establish a channel to communicate, change the settings of the robot on the Orchestrator and then connect it again just by changing the value.
Since to change tray settings one requires admin access, the organisations are not ready to provide local admin access. So it comes to the same question, that someone needs to have local admin access either to stop service or change tray settings. So that’s why was thinking that if Orchestrator can be one stop shop once it is provisioned if possible.
Ok. Changing the settings from Orchestrator…It makes sense for some (Logging Level) but should you be allowed to change the Orchestrator URL from Orchestrator?
I don’t think so - this should be kept at robot level.
From Orchestrator I could definitely see:
logging level (status requirement: Available)
password change (Available or Offline)
(maybe?) username change (Available or Offline)
Changing Orchestrator URL from Orchestrator doesn’t make much sense for me, as the robot keys wouldn’t match (I think). This type of setting I’d leave as-is from the tray, since it belongs more to a dedicated change/migration, not maintenance.
Changing Orchestrator URL to make robot disconnect to change the password is a very convoluted way of doing things that could lead to other issues. Also as far as I know (didn’t test that much, just noticed in the past) if the new settings are incorrect but the previous ones worked, they’d get reverted.