The Workflow activity is the suggested base structure for any workflow. Therefore, it is provided as the default workflow for the MainScriptRunners in every new project. The workflow activity comes with built-in error handling sections, allowing the user to easily resolve potential errors that may occur during process execution.
The Process Section
In the Process section, you can design the entire process within the provided flowchart. Ensure to include all process steps, including decisions and different process variants.
The On Handled Error Section
If a handled error is thrown within the process, the workflow execution continues with this section. Handled errors are errors intentionally raised by the user using the Raise Error activity. In most cases, handled errors are business exceptions, such as process restrictions for special cases, and must be followed by specific actions, such as sending a message to the appropriate person or inbox.
By default, the Clean Application Exit activity is performed at the beginning of this section to ensure that a blank screen is displayed before the defined activity is performed. This ensures that the block is equally usable for errors of different types and at different points in the process. At the end of this section, the Rethrow activity rethrows the previous error to provide this information to the user. The error is written in the database and can be viewed in Hyland RPA Manager.
The On Unhandled Error Section
If unhandled errors are raised within the process, the workflow execution continues with this section. Unhandled errors are identified by the system and are not previously known to the user. These are technical exceptions, such as an activity failing due to Internet connection problems or unavailable websites.
When a system exception is thrown, the unhandled error section is executed and a screenshot is taken because of the default TakeScreenshot activity. In addition, the Clean Application Exit activity executes at the beginning of this block to ensure a blank screen before the defined activity begins. This ensures that the block is equally usable for errors of different types and at different points in the process. At the end of this section, the Rethrow activity rethrows the previous error to provide this information to the user. The user can specify an error remark and ID for the error. We recommend that users re-throw the error remark thrown by the system. The default Raise Error activity is already set to do this. The error is written in the database and can be viewed in Hyland RPA Manager.
The Finally Section
By default, the Finally section within the workflow activity contains only the Clean Application Exit activity. This ensures that all open windows are closed when the workflow is finished.
The Finally block is executed when:
- The process finishes without an error
- The process has reached the section for handled errors and no error was raised in it.
- The process has reached the section for unhandled errors and no error was raised in it.