Attended automation infrastructure

Hi can someone point me to information on infrastructure best practice for attended automation. What is the lifecycle for attended automation (Dev, Test, Prod?) How does it work for a citizen developer building and deploying on same machine?

1 Like

Hello @dgreen!

It seems that you have trouble getting an answer to your question in the first 24 hours.
Let us give you a few hints and helpful links.

First, make sure you browsed through our Forum FAQ Beginner’s Guide. It will teach you what should be included in your topic.

You can check out some of our resources directly, see below:

  1. Always search first. It is the best way to quickly find your answer. Check out the image icon for that.
    Clicking the options button will let you set more specific topic search filters, i.e. only the ones with a solution.

  2. Topic that contains most common solutions with example project files can be found here.

  3. Read our official documentation where you can find a lot of information and instructions about each of our products:

  4. Watch the videos on our official YouTube channel for more visual tutorials.

  5. Meet us and our users on our Community Slack and ask your question there.

Hopefully this will let you easily find the solution/information you need. Once you have it, we would be happy if you could share your findings here and mark it as a solution. This will help other users find it in the future.

Thank you for helping us build our UiPath Community!

Cheers from your friendly
Forum_Staff

hi @dgreen
It’s some thig the same as others.
Whatever the organization that you are following also be implied with attended automation as you mention that’s basically ok.

But when you developing a citizen developer license, you have to check some like below
Is it given to fully handle the entire studio + robot into your staff or not.
Code review definitely should be there
and also if may need to publish into bots (have to test and checks)

and also refer this you may get some ideas for that

What you will always have to take into consideration is the operational environment, the user is working in. In both, attended and citizen developer scenarios, you have a different situation as from unattended ones, as user interaction is far away from standardized. Now humans are interacting with windows, making settings, controlling robot.

Best-practice is to focus on governance and training with endusers. If possible, I would always recommend for a standardized solution, as it is way easier for CoE or IT service desk to debug and find underlying problems. So an example architecture could look like:

Install a terminal server (citrix or native windows) and control standard operational environment through group policies. Lock settings, that you know of, will break certain robot actions, that are being deployed. Connect this machine with Orchestrator to acquire licenses, packages and so on.

This has many upsides in terms of security, operations, scalability and governance, but also downsides, as enduser might not operate in his/her “native” working environment , e.g. their laptop and incurs higher upfront cost.

IMO, the mentioned solution is the only one, that doesn’t turn automatically into a pain in the …, in terms of handling incidents and problems later on and one that eradicates lots of possible problems, caused by endusers - which we all know is the most frequent reason, why robots break :smiley:

1 Like

@kc-x @Maneesha_de_silva thank you for the responses.

  1. Are there any resources that help distinguish the citizen, attended and unattended scenarios.
  2. @kc-x - the solution you describe above requires a terminal server for all citizen developers, yes? How does the automation lifecycle work for citizen development? (Automation Lifecycle) How do citizen developed attended automations migrate through Dev, Test & Prod. Is this possible if you want to develop and execute the same automation on the citizen developer machines?
1 Like

  1. Source: UiPath Presentation; Scenarios are described good for Unattended/Attended. Citizen Developer just means, that typically Business Users can develop their own processes, also utilizing Unattended/Attended.

  2. One terminal server for all citizen developers. Deployment looks the same, as for usual developers. Users might use assets or so in Orchestrator, so giving them access to Orchestrator might be imperative… If you want to automate things, you could use Azure DevOps to create a build pipeline and push from stage to stage. The thing is, that you will still have to deal with assets. Especially if you use sensitive ones (passwords etc.) it’s not that easy to do that 100% automatically. Still hoping for UiPath to publish a native CI/CD / Pipeline integration between OR stages. Also, I would recommend to treat the users environment (in this example the terminal server) as Dev and then have a Nonproduction robot as Test. The Nonproduction robot can also run on the same terminal server as the developers do. Connect both stages to one Orchestrator Tenant and Prod Robot to another Tenant.

To describe further, I attached another slide. This setup is based on a Citrix server and different Workers for Dev/Test and Prod.

1 Like

Hi @kc-x - thank you this is very helpful. Let me give one more scenario. In a case where terminal servers are expensive and citizen developers are working on Studio on their local machine. How would it work for the developer to build and publish to Dev environment but also run attended Prod automations on their machine. This is the conflict I am seeing and looks like it is difficult to separate Dev & Prod environments. Would you advise against this approach?

Well, thats not completely straightforward.
Citizen Developer license comes with Development (StudioX) and Production (Attended Robot) license.

For attended scenarios, business user could just publish to assistant and avoid using Orchestrator altogether —> Dev machine = Prod machine

For unattended, the user would publish to Dev/Test Orchestrator and then deploy to Prod normally. Yet, I highly advise to let business users only develop attended bots.

Downsides: The proclaimed „automate your own process for you AND your coworkers“ is likely to fail in this scenario, as users might have configured their desktops differently.

If I were to build it like the above solution, I would ensure to enforce governance settings for deployment: Governance