In Kofax RPA, you can create Desktop Automation robots that can automate work processes involving Windows and Java applications on your networked computers. Because Desktop Automation is substantially different from website and database automation, Design Studio has a dedicated workflow language and steps for this purpose.

Desktop Automation Robots

The workflow of a Desktop Automation robot is a sequence of steps that are executed one after the other. The steps model how a user would interact with the application that is being automated. To use a Desktop Automation robot, you need to call it from a Web Automation robot with a dedicated action step named Call Desktop Automation Robot.

A Web Automation robot can contain multiple Call Desktop Automation Robot steps, each with their own workflow. A single Desktop Automation robot can be reused by Web Automation robots, which significantly saves time when you work on multiple robots at the same time. The robot with a Call Desktop Automation Robot step can be executed as any other Kofax RPA robot from a schedule, via the API, via Kapplets or manually during development or testing.

Desktop Automation Workflow

The Desktop Automation workflow is edited in Design Studio. In Design Studio, you can see a view of the robot and the applications being automated along with details on the robot state and a dedicated toolbar with buttons to control the robot manually. See Edit Desktop Automation Robot for details.

On the menu, the Help button is available that includes links to the respective documentation and the Getting Started guides that walk you through the process of using Desktop Automation to build a robot.

Steps

Steps are the basic building blocks of a workflow in a Desktop Automation robot. In Desktop Automation, all steps have one entry point and one exit point, except for a few steps that have no exit point. Some steps are simple steps and merely perform one action such as moving a mouse or pressing a key. Other steps, called composite steps, may contain additional steps. Composite steps are used to group steps that belong together or to handle branching and other ways to control how execution proceeds. For the complete list of steps, see Desktop Automation Step Actions.

Steps in Desktop Automation are typically granular and handle smaller tasks. For example, there is no inherent error handling on every step type. Instead, dedicated steps exist specifically to handle errors during execution.

Devices

The purpose of Desktop Automation is automated control of applications. The applications run on devices (computers, servers or virtual machines) that can be remotely accessed over a network. A robot performs Desktop Automation by connecting to Desktop Automation Agents running on remote devices, unless the device is running a terminal, where the connection is direct from the robot. For details about handling devices and setting up the agents, see Configure Desktop Automation Service.

Application Tree

Kofax RPA provides several ways to populate the application tree. By default, Kofax RPA detects the type of application the robot is working with (such as a Windows application, terminal, built-in browser, and so on) and automatically forms the tree for this application. For some Windows applications, Kofax RPA provides extended support. For example, when working with Internet Explorer in Design Studio, Kofax RPA turns on extended Internet Explorer support to retrieve DOM (Document Object Model) tree as it provides a more accurate result in the application tree.

To distinguish between attributes that Kofax RPA receives directly from the applications and attributes that Kofax RPA adds, a set of "derived attributes" is provided. This is done to prevent name clashes between different attributes. Kofax RPA adds the bounding box (x, y, width, height ) as derived attributes. Derived attributes are displayed in the tree prefixed with "der_" and can be used in finders and for extraction.

The following table lists and describes derived attributes that can be used in the application tree.

Derived attribute	Description
For all elements
der_x	X coordinate of the upper left corner of the element.
der_y	Y coordinate of the upper left corner of the element.
der_width	Width of the element (bounding box of the element).
der_height	Height of the element (bounding box of the element).
der_rendered	Set to "y" (for "yes") when the element is rendered on the page.
der_isOffscreen	Set to "true" when the element is not visible on the screen. The page should be scrolled to make the element visible.
For form control (input) elements
der_value	Used for the "email," "text," "number," "range," "tel," "time," "url," "search," "date," "datetime-local," "week," "color," "month," and "textarea" input elements.
der_checked	Used for the “radio” and “checkbox” input elements. Can be "true" or "false," depending on whether the element is selected or cleared.

You can turn off extended application support if you experience issues working with a particular application.

Desktop Automation Robots Compared to Web Automation Robots

Kofax RPA was originally designed for accessing HTML at a time when HTML pages were mostly static. In those cases, the state of the application (web page) can be tracked internally in the robot. By contrast, the Desktop Automation functionality is designed to automate remote applications where the state resides in the application. In this case, the state is external to the robot.

Execution of steps in Desktop Automation move forward only. The state of the execution is on the remote device and it is not possible to undo by going back in the workflow, except for a group of Extract Value and Convert Value steps. As a consequence, when designing your workflow, newly inserted steps are not executed until you explicitly select to do so in the Edit Desktop Automation Robot.

Important Branching, as it is designed in Web Automation robots, does not exist in Desktop Automation robots. It only occurs as part of composite steps.

Branching only occurs as part of composite steps, such as the Conditional. The branches are alternative branches, so only one branch is chosen when a workflow is executed. This differs from Web Automation robots where branches are executed sequentially one after the other, and the state is reverted at the start of each branch.

In Desktop Automation, error handling differs because it is not specified for every step. Instead, a try-catch step explicitly catches errors occurring within its scope and defines how to handle them.

In general, when designing a Desktop Automation robot, think how a user interacts with the user interface of the application you are automating. For example, if you need to type some text in the text field, first click the field and then insert a step that types the text.

Desktop Automation has features that allow the robot designer to design the automation to gauge the external state of the application and react appropriately. For example, a click on a button can be made to wait until the button appears. Or a step can detect that an application is already started, to avoid starting another instance. When you design a robot workflow, guards and finders are used to wait for specific states of the application, ensuring that the robot finds the required elements and interacts with them as expected. Guards are described in the Guarded Choice and finders are described in Finders.

See Get Started to begin automating remote devices and Desktop Automation Step Actions for the list of action steps.