Workflow Instances Activity Monitoring

Daniel White
2025-08-26T13:55:53Z

Overview

The Workflow Instances section offers the possibility to monitor and control workflows that were designed with the new version of the workflow engine.

The Workflows → Services & Processes → Workflows→ Workflow Instances search page lists all instances of workflows that were created with the new version of the workflow engine and provides the search criteria for filtering them (Workflow, Version, State, Last Update, Start, and End). Click the name of the column, e.g. Workflow or State, to filter the grid by this column, A-Z; click it again to filter the grid by this column Z-A.

The grid layout displays the following information:

Quick Filter:

Red rectangle: activation Failed, Terminated or Canceled;

Yellow: Running or Suspended;

Light blue: Completed;

Name of the workflow instance (same as the used workflow)

Version of the workflow instance

State for status of the workflow instance

Last Update

Start

End

Object Preview (when a workflow instance is selected) displays the following information:

Name of the workflow instance

Instance Progress

State

Version

Last Update

Start

End

Summary

Affected Objects

Runs On AppFabric

This filter identifies Workflows incompatible with the Matrix42 Worker Engine. The listed workflows use AppFabric engine for executing the running Instances:

Close the Instances to clear the list.

All the new Workflow Instances must run on the Workflow Worker Engine as the AppFabric engines will be fully discontinued from the next Product version (11.0).

For more details, see Workflow Engine Migration Guide.

Status of Workflow Instances

Statuses of workflow instances can be divided into two groups:

Running Instances:

Active – The workflow is executing some logic.

Suspended – The workflow is waiting for some user input.

Finished Instances:

Completed – The workflow has been completed successfully.

Failed – The workflow failed because of error during the execution.

Terminated – The workflow has been terminated explicitly by the user.

Canceled – The workflow has been canceled explicitly by the user.

The following diagram shows the possible status transitions:

Configuration Item "Workflow Process Instance"

Instance Progress

Visual progress that was defined in the workflow.

General

Name | Name of the workflow instance.
State | Current state of the instance (e.g., Suspended, Active, Completed, etc.).
Start | Start date and time of the execution.
End | Finish date and time of the execution.
Summary | Detailed information about errors in case of a failed workflow instance.
Last Update | Date and time information from the last update of the instance.

Affected Objects

Process Instance Related Object: A list with the affected objects of the workflow instance, e.g., a provisioning workflow instance displays the service booking which initialized the workflow execution (Type, Relation Type, Name).

Actions

Delete

The Delete action performs the delete operation for the selected instances. The system asks for a simple confirmation before the final deletion.

Cancel Workflow

This action will be used to stop the workflow execution and run compensation logic that is defined in the corresponding workflow. As an example, compensation logic for a workflow that creates a user in Active Directory can be removal of the created account. The system asks for a simple confirmation before it finally cancels the instance.

Terminate Workflow

This action will be used to stop the workflow execution without any cleanup (compensation) logic. The system asks for a simple confirmation before it finally terminates the instance.

Suspend Workflow

This action will be used to suspend the workflow execution. The system asks for a simple confirmation before it finally suspends the instance.

Resume Workflow

This action will be used to resume a suspended workflow execution. The system asks for a simple confirmation before it finally resumes the instance.

Reanimate

Reanimate action for the workflows running on Matrix42 Worker is available from 10.0.1 release version.

Reanimate action will be used to re-run the workflow instance that has Failed state. The system asks for a confirmation before it reanimates the instance.

The Failed state can be set with one of the following reasons:

Failure reason | Description

Not started

the workflow instance failed to start:

This might happen if the workflow could not deserialize the arguments, workflow XAML is invalid or broken, necessary Assembly is missing. Matrix42 Administrator should analyze the summary, fix the failure reason and run Reanimate action.

Reanimate restarts such workflow from the very beginning.

Not resumed

this reason is set when the workflow instance failed to resume from a bookmark (for instance, the arguments could not be deserialized because of missing or incorrect assembly version.

In this case, a specific argument type was not found:

Depending on the summary, Matrix42 Administrator can update the server or Matrix42 Worker by installing the necessary version of the assembly and apply Reanimate action.

The workflow instance will be resumed from the bookmark.

Error

this reason can be set in the following cases:

1. Workflow failed during execution, usually because of the unhandled exception in the workflow activity:

2. Matrix42 Worker process was unexpectedly terminated during the Workflow execution:

This may occur when the server connection had been lost or the worker was unexpectedly shut down due to other technical reasons except for the maintenance mode of the system.

In both cases, when running the Reanimate action for the workflow instance with the Error failure reason it is possible that some activities will be executed again which may cause unpredictable behavior (e.g. data collision, duplicates or other conflicts). Therefore, these workflow instances additionally have a warning message that is shown with the default-enabled checkbox for the objects that are going to be reanimated:

Matrix42 is not held responsible for any consequences, data loss or other damages caused by the Reanimate action that is applied for the workflow instances Failed with the Error reason.

If the Workflow instance has been persisted at least once (i.e. stored in the database because of being suspended manually or with a bookmark), on Reanimate action the execution continues from the last persisted state, otherwise, the Workflow instance will be reanimated from the start.

Unsuspended

Reanimate action is not applicable as the persistence point of the workflow instance is not available.

The Unsuspended failure reason is set when the workflow instance failed when the Suspend workflow action had been applied manually or the instance had been suspended automatically on Worker stop, then automatically or manually Resumed but the workflow instance was no longer available in the database.

Terminated

Reanimate action is not applicable.

It is a temporary state that is set if the worker had been shut down unexpectedly and the process information had not been updated for a certain period of time. Worker processes the current status of the workflow process and changes reason to an Error.

Unknown | is set in exceptional cases if other failure reasons are not applicable

All possible failure reasons are stored in the PLSLProcessPickupStateReason Data Definition of a Pickup type and can be accessed from the Administration application → Schema → Data Definition navigation item.

The Martix42 Administrator can analyze the failure reason message provided in the Summary section of the workflow instance preview, fix the issue and apply the Reanimate action. Select the Failed workflows and confirm the Reanimate action:

Clear the checkbox and the objects with the error failure reason will be skipped:

Visual Tracking

This action launches the Workflow Studio in the Visual Tracking mode for the selected workflow instance, where the user can follow up the detailed progress of the instance:

The Flow Chart area shows successfully finished activities marked with a green background and a checkmark.

The Events section provides detailed information about the executed activity, processing time and passed variables so that the workflow progress and each processing stage can be easily traced back and analyzed.