applies to version: 8.2.x, author: Kamil Nędza
How to move large quantities of related elements from multiple workflows with one click.
A process is often built from many intertwined workflows. The simplest relationship between workflows is the one between parent workflows and subworkflows. The main workflow, which represents some form of business model, can have many subworkflows, and those subworkflows may, in turn, have their own subworkflows. In effect, it is possible for there to be dozens of workflow elements. If a “master” mechanism is needed to update or modify all connected elements (for example: Cancel all) from the level of the main workflow – It may turn out to be quite the challenge. This article describes two possible approaches of dealing with this issue.
Designing a sample process:
The process has 3 workflows. The main workflow is the Project workflow. Subworkflows started for the Project workflow elements are called Conduct workflows. These in turn have their own subworkflows: Task workflows. The Project, Conduct and Task workflows are presented below.
Fig.1. Graphical representation of the Project workflow
Fig.2. Graphical representation of the Conduct workflow
Fig.3. Graphical representation of the Task workflow
In this process, we want to implement the following feature: when taking a special Path (i.e. the Big Red Button) in the Project workflow (the main one), the project element, along with all directly and indirectly related elements from the subworkflows, will be Canceled.
Regardless of which approach you take, the first step is always to create technical Paths, invisible to the regular user. These secret Paths will serve as back doors (or a drain system) to flush out related elements from the subworkflows. Every individual subworkflow Step from which we want to remove elements will need to have this technical Path added. In our example we will need to install 5 such technical Paths, on the following steps: “Registration”, “1st step” and “2nd step” of the Conduct workflow, as well as on “Registration” and “Task execution” steps of the Task workflow.
Fig.4. An example of adding a Path to the ”Registration” Step of the Task workflow
The Paths should have the “Validation” box unchecked. What this means is that the system will not return an error in the event that a certain workflow element doesn’t have certain Form fields filled out, even though the Step they are currently on may require them.
Fig.5. $_Cancel_$ Path configuration
Don’t forget to hide your sneaky floodgates from prying eyes! This will also prevent users from accidentally using them:
Fig.6. The unseen Path is the deadliest
Once the cancelation Paths have correctly implemented and hidden, and validation turned off – we can configure a Move workflow (SQL) BPS Action, which will be activated from the main Project workflow element, and will move related subworkflow elements down the cancelation paths we just added.
Approach #1 – Directly targeting Paths:
One method would be to pinpoint the elements and Paths which the workflow has to go through. For the Step on which we want to have the “mass element cancelation” feature (The Big Red Button), add a Path:
Fig.7. Add a Path which will Cancel the entire project
Time to give your Path some firepower with the Action: Move workflow (SQL):
Fig.8. Action for moving workflows
In the Advanced configuration screen for the Move workflow action, create an SQL query which will define what Path the element should take, depending on the Step it currently resides in. Basically, no matter what Step the element is currently in, it will always be forced down the $_Cancel_$ Path.
Fig.9. Query in the Action’s Advanced configuration screen
Keep in mind though, that even though in the above screenshot, all the tags for Paths look the same, they are actually different Paths for each of the 5 Steps. Each $_Cancel_$ Path has a different ID, it is important not to accidentally use the same Path twice. Below is the advanced view of the query:
Fig.10. Advanced edit mode on. Note the different IDs for each of the $_Cancel_$ Paths
The above solution is efficient when the number of subworkflows is relatively small, since configuring them all is not much of an undertaking. As the number of subworkflows increases however, and so does the number of Steps – Correctly configuring everything would be extremely time consuming, and the chances of making a mistake somewhere would be pretty high.
Approach #2 – recursive targeting of all elements.
The second approach has a slightly different SQL query in the Move workflow action config. Instead of directly pointing to the Steps and Paths, we will use a recursive SQL table, which will contain all elements related (directly and indirectly) to the Project workflow. The query retuning a recursive table will look something like this:
Fig.11. Move workflow action configuration using a recursive table
In this example we used, it is necessary that the Paths, which are taken by canceled elements, have the same name and that every Step (except the end steps) have exactly one such Path with that name. In the example we used “$_Cancel_$”. This is because the SQL query relies on finding the Path’s ID based on its name.
Checking if everything works:
Regardless of which approach is chosen, the end effect should be the same – the element from the Project workflow, along with all of its related elements from the Conduct and Task subworkflows will be moved to the Canceled end step. Below is an example of a Project workflow element with a list of related subworkflow elements in various steps of their respective workflows:
Fig.12. View of a Project element form before clicking “Cancel entire project”…
Fig.13. … and after
Both approaches work as intended. However, keep in mind that they both have their limitations. When directly defining which path an element should take, remember that for larger more complex processes, configuring all those action for moving worklows will tedious. For the second method, it is absolutely necessary for the cancelation Path’s name to be identical across all Steps.
This mechanism has a wide range of other applications. A similar system can be implemented to change the values of Form fields in all related workflow elements, or send an email from certain steps of the workflow to users that have active tasks in those steps. The only limitation is the volume of elements being moved at the same time. If the related workflow elements number in the hundreds it would be wise to set up extra security measures, like limiting the number of elements being moved at the same time.