Blocks: Overview
A block is an optional step action that can be used to sense when a user performs particular action (the "triggering action") on the target application, such as clicking on a certain button or entering specific keyboard combination. When the block detects this action, it performs the logical sequence defined by the RPA developer.
The following are the major considerations when using a block:
-
Whether to allow/deny/store the triggering action (Behavior)
-
What the wizard should do next (When clicked/pressed)
-
If/how/when the block is removed (Block duration)
Block types
You can choose from various types of blocks – varying by the triggering action and resulting screen area/key combination blocked:
-
Screen block: When the user clicks the mouse in the target application, the entire screen is blocked – regardless of the applications currently open or active on the screen
-
Window block: When the user clicks the mouse in the target application, the active application window is blocked
-
Object block: When the user clicks the mouse over a predefined area of the target application, that area is blocked
-
Certain properties (namely, block position and fallbacks) are relevant only to object blocks. For additional information, see More About Object Blocks.
-
-
Key block: When the user types a predefined key combination affecting the target application, the resulting action is blocked
Why use a block?
Blocks have a wide array of uses, depending on organizational needs. These uses can be classified into two main purposes:
-
To ensure user compliance with defined processes
-
To augment application functionality
Example
After filling in a form, the user clicks OK. To help ensure that form is completed correctly before it is submitted, you can use a block to:
-
Sense when the user clicks OK
-
Hold the click before allowing it to go through to the application (while the wizard validates that the form is completed correctly)
-
Based on the result of the validation, decide whether to: (1) release the click to the application; or (2) deny it and prompt the user to fix any incorrect data
Development
In Studio, the RPA developer would:
-
Record the form window in a sensor/wizard
-
Apply a block to the form's OK button to sense the user's click
-
Apply a read from screen validation on the form fields
Wizard runtime
In the user's environment:
-
The user completes the form and clicks OK to submit it
-
When the user's click on OK is sensed, the block stores the click to memory, not letting it go through to the application
-
The wizard/sensor runs a read from screen validation to ensure that the form was completed correctly
-
If the form was completed correctly, the wizard releases the user's click and allows it to go through to the application (i.e., resulting in the form being submitted)
-
If the form was not completed correctly, the wizard prompts the user to fix it, then restarts the block process from step 1