Consuming automations

You know who your consumers are, but how do they actually interact with your robots?

May 30, 2021
854 words (5 min read)
RPA Program


I talked about who the consumers of your automations are in an earlier post. But that post left a gaping hole: what are the mechanics of how people interact with automation? This post aims to rectify the situation by providing an overview of the different ways this can work.

Attended vs Unattended

You’re likely aware of the difference, but just to make sure we’re on the same page, let’s reiterate. There are two ways you can execute an RPA process: the first is called attended and refers to the robot running on the consumer’s computer. The second is called unattended and will have the robot run on a different computer, usually a VM or server.Some vendors, including UiPath (picture in picture) also offer something in-between where the robot runs attended but logs in a separate session


Let’s start with attended automation first. The typical idea here is that the robot has to interact with a human operator in some way.

Play button

The simplest most straightforward way to execute an RPA workflow is by starting it through a GUI provided by your RPA vendor. This may or may not let you specify arguments for each run. The robot will run when you want it to and do precisely what you ask it to do.

This approach is most suitable to smaller automations. There are some variants: providing a desktop shortcut or start menu entry, keyboard shortcut, etc. that are very similar


The second most common approach might be to provide a custom GUI to your consumers. This could include a web app (UiPath: using the JavaScript library), a vendor-provided low-code solution (UiPath: Action Center, Forms or Apps), a third-party tool (e.g. BPM), a local application that interacts with the robot in some way (named pipes or HTTP calls), etc.

The most common scenario for this seems to be building some sort of automation dashboard or digital assistant that helps you do smaller tasks more efficiently, or gathers information for you while you talk with a customer.

Logon trigger

Another common variant is to automatically run an automation when the user logs into Windows. This can increase startup time but is useful for things like automatically preparing certain applications.

Run forever

A subtype of the logon trigger is to have one or more processes that continuously run in the background and either perform a task periodically or wait for something to happen (e.g. a file being dropped in a hot folder). This is the second leg of the digital assistant scenario and often combined with Apps.


In the unattended area, things become a little less clear-cut. Robots may run completely unsupervised on their own (using schedules or other triggers), or they can require human interaction at certain points.

Backend processing

The most straightforward scenario for unattended automation is that the robot won’t require human interaction and just run on its own. Usually this means scanning one system for input data and then kicking off the desired actions. This is basically the RPA version of a script where every step is pre-determined.

Being the default mode for unattended automation, this is most applicable for end-to-end process automation or automated reactions to customer requests (chatbots, ticketing systems, e-mail, and so on).


In this scenario, the robot will be triggered by a human, but execute unattended (UiPath: Apps, Action Center or Orchestrator Mobile). The user will have to provide all required information at the beginning and the robot will then do its thing based on this data.

This is probably most commonly used with files or file paths as input, e.g. documents or Excel lists that define a sort of runbook. It can, however, also involve API calls from other applications that the consumer is using and which dispatch the work to a robot in the background, for example BPM tools like K2.

Human in the loop

A step up from being merely triggered by a human are automations that involve human operators multiple times in the process. This can either be initiated by the robot requesting data (e.g. via e-mail), or by the human sending something to the robot (e.g. a file in a hot folder). Common examples are document validation, communication with 3rd parties, or approval scenarios. (UiPath: Action Center and Long-running workflows, Apps, chatbots)

Hybrid automation

Last but not least there are scenarios where the user interacts with an attended robot, which in turn loads off some or all of the work to an unattended counterpart. The most common vehicle for this is a work queue, but some vendors also provide ways to call an automation directly through an API call.

Is that all?

Well, it’s all I could think of. Let me know if I missed something, or you disagree with my categorization. Thanks for reading, and, as always, see you next time in the best of spirits!

© 2021, Stefan Reutter