Error handling in workflows

General error handling

If errors occur when using workflows, the error handling approach depends on whether the error arises:

When starting: If an error or an exception occurs when starting a workflow (because the user does not have permission to switch a workflow's transitions, for instance), the workflow is not started for the object.

When switching: The situation is different if the workflow has already been started and an error or exception occurs while switching a transition. In this case, the status prior to switching the transition, i.e. the last "error-free" status, is retained. If an error status is defined in the workflow model, the element will be in the error status after the exception occurs.

Error status

There are many reasons why an exception could occur when running a workflow, such as improper configuration in the workflow model or a script error in an attached script. In order to reliably catch these errors and prevent an instance of the workflow from being in an inconsistent status after switching a transition, an optional error status is available in the modeling for workflows.

This is simply a question of adding a status element of the “Error” type to the workflow model (see Status properties). The status is then shown with a red border in the model.

An example of a workflow with error handling can be found in the Tutorials Chapter.

The task list provides an overview of all instances of the workflow that generated errors when they were run.

Clicking the “Status” label in the table sorts schedules by their current state.

Only one error state is permitted per workflow. If a state is defined as the error state even though an error state already exists in the workflow model, the first state is automatically reset to the “Normal” type.