Can I purposely prevent users from publishing to the orchestrator but remain attached to the orchestrator

Now that we have our CI/CD pipeline established it doesn’t make a lot of sense to have orchestrator-connected studios publish their processes directly to the orchestrator just to have the CI/CD system do the same thing when their code is checked in. Is it possible to allow studios to connect to an orchestrator for reading assets but prevent them from publishing packages? This would force them to check in code and have the CI/CD pipeline deploy their bots.

2 Likes

HI @cclements

I’m not 100% sure about this… But just thought of mentioning it…

Have you tried checking the robot roles in the orchestrator? Based on the role permissions, I think you might be able to get it done by removing some permissions from the robots that you wish to stop the publishing from…

Let know whether it helps…

I’m not going to comment on that :shushing_face:, because the loophole is like that path of least resistance that comes in play occasionally. And, I feel that the developers should have freedom to explore certain things where they don’t constantly run into a wall. While at the same time, still following the standards for version control and deployment.

@cclements
I think UiPath might be talking about ideas to improve the Publish button to integrate more with TFS or even between Orchestrators. I know it has been a popular topic for a long time. I have no idea where UiPath is on this topic though. But, we have brought the concern to UiPath within my company I know.

1 Like

Does anybody have any updates regarding this issue? I have exactly the same situation: we established a CD/CI pipeline in Azure DevOps and I would like to disable the option to publish directly from Studio to Orchestrator. I just deleted all roles for my user in the Orchestrator and could still publish packages…

You may not be able to prevent developers from publishing, but you may be able to achieve the same effect with personal workspaces (only in version 20.4), devs can be restricted to publish only to their personal workspace which acts very similar to a modern folder. Any packages published to the personal workspace is not visible to other users. And the packages deployed by your CI pipeline could be directed to whatever folder you want.

2 Likes

I equally need a way to do this my internal audit team is requiring we have a way to prevent developments from going into “live” systems without going through our checks and testing process.

Is there a way to restrict certain applications via governance?
Is there a way to prevent automations being run with certain application titles? for example our ERP is Microsoft Dynamics 2012, when it starts our Dev box has a name in the title its something like “AX 2012 DEV” and then prod is “Prod” if I could prevent the automations from being used with prod until we review at the COE that would work.

Hello @Nathan_Betters ,

You can finetune the selectors to meet this requirement. Because in the selector there can Title attribute and you can use the environment wise title.

But if you did it again it will be a rework to modify the slectors for production environment. In most of the cases if titles are different, then inorder to work in all environment we need to modify the title values with wildcards “*”

This does not solve the problem because its something the developer can change. I need to Prevent the developer from working in our production environment. Can this be done via governance policy?

Does anybody have any updates regarding this issue?