Massive update of sub-workflows in WEBCON BPS

How to massively update multiple WEBCON BPS workflow instances. How to cancel all active WEBCON BPS sub-workflows?

Every complex process has a sub-workflows

Today’s post follows my post “Moving workflow elements en masse” from 5 years ago on the massive cancellation of all sub-workflows. Today I would like to present the simplest possible way of updating all instances of WEBCON BPS that are related to specific main workflow instance.

Every more complicated process will consist of multiple workflows. Many WEBCON BPS administrators face the problem of how to terminate the user’s tasks of all sub-workflows when the main workflow is canceled. For example, when a project is canceled, all tasks for that project should be canceled. Of course you may configure many actions per every sub-workflow step but this approach does not scale in any way and is very time consuming. Below I will show you my way.

Example process and our goal

Let’s say we have a one main workflow, and 2 other sub-workflows like below:

Our goal is to create a functionality that will allow us to cancel all active sub-workflows when the main workflow is canceled. All active sub-workflows have to be canceled no matter which step they are in.

Sub-workflows configuration

To achieve this, the first thing we need to do is modify our sub-workflow diagrams and add final negative step and cancellation paths from each step.
CAUTION: Every path must have the same name. In addition on every step this path name must be unique. This condition is necessary, because in the next step we will make an SQL query which will return specific path ID by it’s name.

When adding each of path make sure that below conditions are met:

1. Path is not visible – this will be a technical path that will not be accessible to user from the sub-workflow forms.
2. On path transition user’s task will be canceled – this setting is necessary to be able to leave step. If a task is not completed/canceled on a step, the workflow will remain in the current step and will not go to the next one.
3. Form field validation and comment requirement are unchecked – we won’t be able to move sub-workflow when some form fields or comment will be mandatory.

Main workflow configuration

When we do the configuration shown above we are ready to configure a “Move workflow (SQL)” action on main workflow. The purpose of this action is to move each of active sub-workflow which have relation to our main workflow to the “Canceled” step. No matter in which step it is.

Add “Move workflow (SQL)” on your main workflow on “Cancel” path:

As path ID you may set any integer value. There is no matter what value would it be, because we will return PATH_ID column in our SQL query for each workflow instance. Values in this column will be used by system instead of static parameter. Also make sure to uncheck “Check logged on user privileges to move workflow instance”.

As SQL query put this query (of course replace your path name and form type IDs):

Select WFD_ID, PATH_ID from WFElements
join WFAvaiblePaths on WFD_STPID = PATH_STPID
join WFSteps on WFD_STPID = STP_ID
where PATH_Name = 'XXX' --Replace your's path name here
and WFD_DTYPEID in (0, 0) --Replace your's form types variables

Functional test – cancel all sub-workflows

Let’s check how it works. Below is a form of my main workflow which is in “Active” step. On the form there are listed all the related sub-workflows and their status (current step).

After picking the “Cancel” path, the action configured by us is started, which moves all related workflow instances. The result is shown below:

Another example – transfer all task from one user to another

The same mechanism can be used to move all tasks of our sub-workflows from one user to another. Let’s modify our workflows like this:

As before when adding each path of sub-workflow make sure that below conditions are met:

1. Path is not visible – this will be a technical path that will not be accessible to user from the sub-workflow forms.
2. On path transition user’s task will be canceled – this setting is necessary to be able to leave step. If task is not completed (or canceled) on a step is, the workflow will remain in the current step.
3. Form field validation and comment requirement are unchecked – we won’t be able to move sub-workflow when some form fields or comment will be mandatory.
4. Uncheck status icon change – workflow instance will remain in current step. We do not need to mark step as finished.
5. Assign task to new “Assigned person” – this will assign task to new user
6. And send email – we want to notify our user that he received new task.

Now go to main workflow configuration. Firstly add 2 new people form fields. One for the user to whom we want to revoke the rights and the other for the user to whom the tasks are to be assigned. Then go to step configuration and add “Move workflow (SQL)” action on proper path. The purpose of this action is to move each of active sub-workflow instance which have relation to our main workflow using”$Save$” path to transfer all tasks from one user to another.

As before path ID may be set as any integer value. Also make sure to uncheck “Check logged on user privileges to move workflow instance”.

This time in SQL query we filter result set to sub-workflow instances where currently assigned user is the person selected by us on form. We also need to add additional column where new assigned person will be returned. Below is my example:

You may also add another action which will clear values of people form fields after making task transfer.

How it works

After choosing source and destination task users, we can use “Change user” path to reassign all active task that met source user condition.