Attended RPA and Forms

There’s more than one way to automate a process—but results may vary. That’s why it’s critical to understand the different types of process automation so you can determine how to build a workflow that will best meet your goals. Let’s start by discussing unattended vs attended RPA.

In unattended automation scenarios, the bot executes without any human participation. An attended bot, on the other hand, requires human interaction for the automation to complete. For example, invoice approval processes typically require a human to approve invoices above a certain threshold. Attended RPA is sometimes referred to as person-in-the-middle automation.

In attended RPA, human interaction is gathering data, and one of the most common ways to gather data is to use forms. Below we discuss using a forms management solution with an RPA application to implement attended automation, what to look for in a forms solution and how a forms solution greatly expands what can be automated.

Forms and Attended RPA Use Cases

Forms are widely used in attended RPA scenarios. Some of the more common use cases are approvals, user registrations, application processes (e.g., loan applications), questionnaires, surveys, and more. Another area where forms are prevalent is in support scenarios. For example, creating IT support tickets and facility maintenance requests.

By studying these common use cases we can identify the requirements for an RPA forms solution. We break these requirements down into process flow requirements, how the forms are invoked, and data requirements.

Process Flow Requirements

The process flow looks at the business logic associated with the forms part of the application. At the highest level it can be categorized into single-form and multi-form applications. While these are self-explanatory categorizations, it is important to note that multi-form applications can be further divided into linear flow applications and parallel flow applications. 

Single-Form Applications

Forms application requirements for RPA use cases can be as simple as presenting a single form to the user. The user fills in the data and submits the form. An example of such a use case would be a basic approval process—support tickets and facility maintenance use cases are commonly single-form applications.

Multi-Form Applications

Some use cases are multi-step processes that require different forms to be presented to the user. For example, surveys and approval processes can be multi-form applications. Some multi-form applications can be more complex than others. The complexity is not necessarily the number of forms that need to be presented, but rather, the need to introduce conditional logic into the process.

Linear-flow forms applications are multi-form applications where the process flows from one step to the next until all the forms have been presented to the user. For example, surveys are, in general, multi-form linear-flow applications.

Approvals, on the other hand, especially more complex approval processes are parallel-flow applications. In parallel-flow applications, the application can take different paths depending on the responses in the previous form. Figure 1 shows a parallel-flow approval process. In this process Obtaining Completed Credit Application, Submitted to Controller for Approval, and Requesting Other Payment Forms, are steps where forms may come into play depending on different criteria. 

Image

Figure 1: Parallel-Flow Approval Flow

Invocation Requirements

Forms applications can be notification based or user invoked.

The approval process discussed above is a notification-based application. In this type of application, the user is informed, by email or other means, that a form is awaiting their input.

In some use cases, the form is initiated by the user performing an action such as clicking a button on a website. IT support tickets and maintenance request applications are examples of such applications where the user initiates the form based on need.

Additional Requirements

Forms applications can have an exhaustive list of additional requirements, and while providing an exhaustive list is beyond the scope of this paper, here are a few key features of note:

• Support for forms templates
• Access and permission controls for managing and updating forms
• Versioning of forms
• Audit control
• User authentication to record which user is providing form data

The Role of RPA in Data Collection

Forms applications may be sufficient to satisfy all the requirements of some attended RPA use cases. For example, a maintenance request application may be supported by creating a web page with a form that, when submitted by a user, sends an email to the facilities manager. But in many scenarios being automated, data collection is only a part of the scenario.

In the purchase order approval process discussed above, many of the steps do not involve data collection. For example, PO From an Existing Customer is the RPA application driving the process and incorporating forms into the process where needed. In this example the purchase order may be dropped into a folder on a drive that is being monitored by an RPA application, or it may be sent to an email address that is being monitored. When a purchase order is received the RPA application then sets the process into motion. By combining a forms solution with an RPA application you are able to expand the business processes that can be automated.

RPA and Forms Solutions

Fortra supplies a robust, easy-to-use RPA solution in Automate. Automate can be used with any forms application to implement attended RPA. For example, there are many free forms applications such as Google Forms, and if you are a Microsoft shop, you may have free access to Microsoft Forms. While these forms applications are sufficient for simple data collection applications, you may want to consider a forms application that supplies greater functionality, better integration, and support for form control and distribution. Two such dedicated forms solutions from Fortra are WebDocs Forms Management and GoAnywhere Secure Forms.

To learn more, explore the following resources:

• Google Forms May Be Free, But Does it Give Your Organization All It Needs?
• Three Reasons to Choose a Dedicated Forms Management Solution Over Power Automate

WebDocs Forms Management supplies a web-based, citizen developer interface that allows users to drag and drop elements on forms and configure them without any required programming knowledge. WebDocs form submissions can be stored outside of WebDocs in several ways. The form data can then be e-mailed to a mailbox being watched by Automate with the data in XML format as an attachment. The WebDocs FileSystem Connector saves submission form/workflow XML document(s) to local or remote file systems which can then be accessed by Automate for processing. WebDocs form data can also be sent via a RESTful API which will send the updated XML information into Automate’s internally exposed API service for processing.

The Secure Forms module in GoAnywhere, allows end-users to fill out custom forms through the HTTPS Web Client. Secure Forms can then be designed with configurable input fields and custom labels to control the data end-users supply during form submission. The submitted forms can then be attached to projects in GoAnywhere which can use the GoAnywhere-Automate Enterprise Cloud Connector to send a RESTful API call to execute an Automate workflow or task.

A key benefit that GoAnywhere Secure Forms provides is, of course, security. Along with data masking and data encryption, Secure Forms provides ICAP integration which leverages Clearswift’s ICAP Gateway, and provides threat protection—which is especially useful when the use case requires the public to have access to forms and the user trust is unknown. This can ensure that the form is not processing an infected file.