Advanced Parallel Task Handling: Voting-Style Decisions

Applies to version: 2021 R1 and above; author: Mike Fitzmaurice

Introduction

WEBCON BPS offers several ways to handle parallel work. If the scenario involves a single task assigned to multiple people, a few task configuration settings are usually all that is needed. There are exceptions to this, though, especially when you have elaborate criteria to apply to the task results.

The Scenario

Consider the workflow below.

During the step named “Review”, a set of people are tasked with choosing the “Yes” or “No” path. WEBCON BPS provides a means to handle situations where different reviewers might make different decisions:

First Response Wins

If you only need one response, this is easy to handle. The simplest option is to configure the “Submit” path’s task parallelism to Completion – Any, like so:

But it’s also possible to achieve the exact same effect by setting the “Submit” path’s parallelism to Completion – All and then having the “Yes” and “No” path parameters to “Set other tasks as cancelled”.

That second example more closely matches what WEBCON BPS’ workflow engine is doing behind the scenes. Moreover, it serves as a better starting point to explain the next most common option…

All or Nothing

For scenarios where a specific number of “Yes” path choices are needed before an approval path can be chosen, you can set the Operation executed on parallel tasks to Wait for required tasks to be completed and set either Fixed number for a specific number of “Yes” responses, All for unanimous “Yes” responses, and Percentage for, well, a percentage of task responses being “Yes”.

And everything will work as expected if one of the following two conditions is true:

• The “No” path’s Operation executed on parallel tasks is set to Set other tasks as cancelled.
• It’s set to Wait for required tasks to be completed with Number of required completed tasks set to a fixed number of 1.

In this scenario:

• The step is finished when even a single “No” path is chosen, even if not all tasks have been completed.
• It also ends immediately if the required number of “Yes” choices have been received.

And if that is all you need, you can stop reading this right now. But you might need more.

The Problem

Perhaps you need to collect responses from all task assignees first, and only after examining the results can you determine which path the workflow should follow. There is no way to handle this by simply adjusting the settings for Operation executed on parallel tasks and Number of required completed tasks. Let’s say you had assigned a step to five people, set the “Yes” path to require 3 completed tasks, and set the “No” path to require 2. Here are two outcomes that would happen that are correct despite being counterintuitive:

• If the first response was “No”, the second was “Yes”, and the third was “Yes”, the workflow would follow the “Yes” path.
• If the first response was “Yes” and the second was “No”, the workflow would follow the “No” path.

In both examples, it “feels” like the workflow engine made its decision too soon. But the setting Number of required completed tasks is meant to be taken very literally. It does not mean the number of tasks for which this path was selected. It simply means tasks completed. When each task response is received, the workflow engine evaluates (a) which path was chosen, then (b) whether the settings for that path now allow it to continue along that path. In the above two examples:

• The second “Yes” response caused the engine to look at the “Yes” path’s settings, which said it could be followed if three tasks had been completed.
• The first “No” response caused the engine to look at the “No” path’s settings, which said it could be followed if two tasks had been completed.

The Solution

It is quite possible to get the desired voting-style behavior from WEBCON BPS using one or two SQL queries together with a Workflow Control step. Moreover, the SQL queries can be encapsulated onto global business rules that can be reused repeatedly.

At a high level, it looks like this:

Part One: Business Rules with SQL Queries

You will need to create three business rules.

• “Vote Count Total”: the total number of all completed tasks, regardless of which path choice was made.
• “Vote Count for Path ID”: the number of completed tasks for which a particular path was selected (button was clicked). It will need you to supply the ID of the path you want to examine.
• “Vote Results”: a text representation of the list of each person who completed a task, and what their path choice was. This is useful for adding to multi-line text fields, if not the system-provided Comments field.

In all cases, we will not retrieve all tasks associated with the current process instance – just the tasks that were most recently assigned/completed. Ideally, these should be global business rules, as they can apply to any process in any application.

Vote Count Total

This is the easiest of the three rules. It consists of a single SQL COMMAND function, and it has no parameters:

The SQL statement inside the function looks like this:

The specific SQL text is:

SELECT COUNT(*) AS [Vote Count]

FROM WFElementTasks

WHERE WFT_WFDID = {WFD_ID}

AND WFT_Version = (SELECT MAX(WFT_Version) FROM WFElementTasks WHERE WFT_WFDID = {WFD_ID})

AND WFT_FinishPath IS NOT NULL

The query makes use of the WFElementTasks table, which contains specific task assignments – and their results – for a process instance. As mentioned earlier, we query only the entries from the most recent version (set of tasks issued at the same time).

Vote Count for Path ID

This rule is slightly more complex than “Vote Count Total”. It requires creating one decimal parameter named “Path ID”, and using it in the WHERE clause to filter the results of the WFT_FinishPath column:

The specific SQL text is:

SELECT COUNT(*) AS [Vote Count]

FROM WFElementTasks

WHERE WFT_WFDID = {WFD_ID}

AND WFT_Version = (SELECT MAX(WFT_Version) FROM WFElementTasks WHERE WFT_WFDID = {WFD_ID})

AND WFT_FinishPath IS NOT NULL

AND CONVERT(int, SUBSTRING(WFT_FinishPath, 1, CHARINDEX('#', WFT_FinishPath)-1)) = {Path ID}

The text “{Path ID}“ should be replaced with a reference to the “Path ID” parameter. 

The reason for the CONVERT() and SUBSTRING() functions is that the WFT_FinishPath value is in the format of “ID#Name” (a format common to WEBCON BPS), and we only want to compare the ID.

Vote Results

This final rule resembles that in “Vote Count Total”, but with a more elaborate SELECT clause. Rather than counting task responses, it lists them (the author and the chosen path). As such, the rule should return all rows, not just the first one:

The specific SQL query text is:

SELECT CONCAT(

  WFT_UserName,

  ': ',

  SUBSTRING(WFT_FinishPath, CHARINDEX('#', WFT_FinishPath)+1, LEN(WFT_FinishPath))

) AS [Vote]

FROM WFElementTasks

WHERE WFT_WFDID = {WFD_ID}

AND WFT_Version = (SELECT MAX(v.WFT_Version) FROM WFElementTasks v WHERE WFT_WFDID = {WFD_ID})

AND WFT_FinishPath IS NOT NULL

ORDER BY WFT_UserName

It will return results in the form of “User Display Name: Path Selected” in a single text block, with rows separated by semicolons. As such, the rule uses STRING REPLACE to modify the SQL COMMAND results, replacing semicolons with new line characters. The new line character is supplied using the TEXT function, as seen in the following illustration:

Inside the TEXT function, the Enter key has been pressed once and the text cursor is now at the beginning of the second line.

Part Two: The Path Settings

Each path leading away from the Intermediate step where “voting” is taking place should be configured to Wait for required tasks to be completed and for the number of required completed tasks to be All:

We want every task assignee to respond, no matter what their chosen path response is. We’ll decide which path to take in the Workflow control step that follows this Intermediate step.

Part Three: The Flow Control Step

The Workflow control step’s path selection rule will make use of “Vote Count for Path ID”, and may need “Vote Count Total” as well. In the following illustration, we follow the path named “Reject” if we receive even one “Vote No” path choice:

For more elaborate decision making, the following illustration shows how to have the workflow whichever one of two paths receives a majority (> 50%) of votes, with a tie going to whichever path has been set to be the default:

The path ID values can be obtained from the Object browser tree as shown above, or by the rules editor’s autocomplete feature as shown below:

While not explicitly necessary, you may well wish to something like list of the choices each task assignee made to the workflow instance’s Comments field. You can do this by adding an automation to the On entry event of the Workflow Control step. It needs one Change value of single field action configured to set the value of the built-in [System] Comments field to equal the outcome of a business rule we’ll create called “Vote Results.”

In Conclusion

As mentioned before, not every workflow needs to handle voting scenarios, situations in which we must wait for all responses and then examine them. But such scenarios do exist, are important, and can be handled by WEBCON BPS using the technique covered in this article. By using this technique, nearly any type of decision criteria can be applied to the outcome of a voting-style set of task assignments. The extra complexity required is confined to three business rules that can be scoped globally, created once, and reused widely. The rest is straightforward rule logic that should be common knowledge to WEBCON application builders. A strength of WEBCON is that the platform allows for bypassing these limitations, even if doing so requires extra work. A further strength is that the platform is being continuously enhanced, and it is this author’s hope that this article will one day no longer be needed.