(800) 286-4232 info@ratchetsoft.com
 

Attended Versus Unattended Bots…Aren’t They All Just Bots?

Rows of metallic robot androids of various metals or alloys

Well, in a word, “yes”. However, they usually serve different purposes, are deployed, administrated and monitored differently, and are often licensed differently by RPA vendors so understanding the differences between the two is important.

What is an Attended Bot?

An attended bot is a bot that executes its automation on the user’s local workstation. Attended bots can be invoked in any of the following ways:

1) Via the RPA product’s client tool. This method is most often used by general purpose bots that can be invoked regardless of the user’s desktop state. In other words, the bot does not rely on the user’s desktop or applications to be in a specific state to run properly. An example of this style might be a bot that extracts the value of highlighted screen text and performs a Google search. It doesn’t matter which application is loaded. As long as text is highlighted, it can run. However, there is no hard and fast rule that mandates a bot invoked in this fashion be general purpose or even desktop state independent. A bot invoked in this fashion may be highly dependent upon state, but requires the user to establish that state before invocation. While this latter method is valid, it is not advised and method 2 described below should be considered when desktop state is an issue.

2) Via an embedded screen button. Embedded screen buttons, or what we call in Ratchet-X, magic buttons, allow the user to invoke a specific bot only when the workstation is in a state that warrants its execution. We call this the “context”. The context is defined by the following: a) active application, b) active screen, c) screen state, d) data available on the screen, and e) the logged in user. Once the context is defined, the RPA tooling can decide if a screen button should be embedded and which bot(s) can be invoked.

For example, if a bot’s job is to check and see if a phone number is on a Do Not Call Registry (DNC), the bot should only be available for execution when the active application screen contains a valid phone number and the logged in user has a requirement to check registry status for outbound calls. So people working in a call center may see the embedded button while folks working in a back office might not.  

Finally, embedded buttons can be contextually positioned on a screen so they appear next to the data upon which a bot will act. For example, if you have a screen that contains multiple phone numbers, you can perform a DNC check on one of the specific phone numbers by clicking the embedded button next to the phone number you want checked.  

3) Via an existing screen UI element. In some cases, you may want a tie a bot’s invocation to the user’s on-screen activity rather than requiring the user to explicitly invoke the bot. Going back to the DNC check example, rather than requiring the user to click an embedded button to perform the DNC check, the user may be better served by “attaching” the bot’s invocation to an activity the user must perform which coincides with the check. So let’s say the application screen that contains the phone number also gives the user the ability to dial the phone either by clicking on a UI element or by pressing a hot key combination. We could attach the DNC check bot’s invocation to that activity, so that when it occurs, the bot can be invoked, perform the check, and then based on the result (i.e. call allowed or disallowed), pass or not pass the activity back to the underlying application for processing.

Attaching bot invocation to an application’s UI activity is a very powerful capability. However, be very careful when employing it because the invocation is automatic. In practice, we find most users who want this automatic invocation come to realize that they traverse application screens for many purposes other than the purpose the bot is supposed to support resulting in unnecessary invocations. This is especially the case when a bot’s execution is attached to the mere appearance of an application screen (i.e. auto invocation).

At first glance, one might think if a bot requires user intervention (“user-assisted” automations), it should be executed by an attended bot. However, in the wild, we have seen many of examples of user assisted and non-user assisted automations executed by attended bots.

 What is an Unattended Bot?

As the name implies, an unattended bot is a bot that runs on a dedicated workstation (usually a virtual machine or virtualized desktop), and executes automations that generally do not require user interaction. These bots are invoked via methods other than application embedded buttons or manual invocations from RPA tooling. You may have noticed I used the phrase, “generally do not require user interaction”, as part of the description. I say “generally” because even though unattended bots are not designed to be watched (aside from normal logging), advanced RPA platforms like RatchetSoft’s Data Entry Bots (shameless plug), do provide a monitoring mechanism that allows unattended bots to reach out, or “prompt”, a human in real time to assist bot processing if needed rather than merely forcing the bot to throw a log exception. Unattended bots are often used to handle batch processing automations or field ad hoc requests from other applications, functioning much like a traditional web service.

Common Invocation Methods

Since unattended bots are not invoked by the desktop user, what are the most common invocation methods for unattended bots?

1) Presence of a data file in a network share resource. Most unattended bots are triggered by the depositing of a data file in a network share resource (e.g. shared drive, WebDav, ftp folder, etc.). Common data file formats include: XML, CSV, XLS and EDI. Once the file is deposited into the network share, the bot, either through polling or receiving a message, opens the file, parses its contents and performs the required automation on each record in the file. Though a file may consist of one record to be processed, more often, the file contains a collection of records and are processed in batch. For example, the file may contain a listing of all the day’s invoices.

2) Timer. An unattended bot may be invoked by a timer that triggers the same time every day or multiple times a day. Timers are also used to trigger queries into backend databases looking for conditions that warrant the invocation of the bot. For example, “execute this automation for all new hires with a start date of today”.

 3) Ad hoc request. Sometimes, an unattended bot is designed to handle ad hoc requests from other applications. In these cases, the bot can be given a REST interface so it appears to the external application as a web service. For example, a bank may want to allow its customers to access account balances via phone but can’t create the required interface to the core system the IVR engine needs to make the request. In this case, the bank can easily create an unattended bot that knows how to acquire a balance for an associated account number. So when the call comes in and the customer supplies an account number, the IVR system in turn makes a call to the bot’s service interface. The bot then logs into the core system, issues the query, finds the account, extracts the balance, and returns the value to the IVR system. The IVR system then reads the value to the customer. All of this can happen within seconds.

Keep in mind that ad hoc request invocations do not necessarily require a traditional services interface. Ad hoc bots can also be invoked based on the receipt of a text or email if the situation warrants.  

Finally, while there is nothing technically wrong with equipping your bot with a specific invocation method, most advanced RPA platforms abstract that responsibility away from the bot and house at a higher level within the platform. So rather than a specific bot initiating the invocation, the platform handles the invocation, performs any required data or messaging preparation, and then in turn, distributes the request based on business rules to a series of downstream bots. This abstraction makes the unattended bots more atomic, durable, and versatile.

The bottom line is attended bots and unattended bots are all just bots that perform specific tasks. Understanding the differences in how they are invoked, which often have deployment strategy and licensing implications, is important when designing your RPA plan. It is all about delivering the right service at the point of need.

Submit a Comment

Your email address will not be published. Required fields are marked *