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.
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.
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 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.
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.
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.
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.
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)
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.
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!