we are currently modeling the workflow of our new project. Most parts of this workflow consist of normal “user tasks”. However, for one of these “user tasks” we have the following requirement. We have a solution but we are not sure if there is a more elegant way:
When the process instance waits at the user task “concept”, the assignee has two possibilities:
complete this task or
create tasks for his/her colleagues. In this case these tasks have to be completed before the user task “concept” is allowed to complete. It must be ensured that the “after concept task” is only called, when the “concept” Task and all assigned “sub tasks” are completed.
Our solution: the concept phase is a subprocess, which contains a normal flow (start event, service task, user task, end event). In order to cover point 2, a “non interrupt signal” is attached to the “concept user task”. The inner subprocess will be called each time a signal is sent. This inner subprocess contains the “user sub task”, which must be completed.
The non-interrupting signal does not strictly prevent the user from completing the concept activity anyway. Having a subprocess is rather a workaround that process flow does not continue afterwards.
Signals are global. Whenever you submit a signal of a certain type, all process instances waiting for that signal are going to receive it.
As an alternative, I propose to use subtasks, i.e. when the user decides there should be something done before the current task completes, you create a subtask via TaskService#newTask and Task#setParentTaskId. Now, there is no built-in mechanism that prevents the user from completing the super task when sub tasks are still present. You could implement that yourself, however, by using a TaskListener and registering it for the complete event of the super task instance. In that listener, you could make a query for existing sub tasks using TaskService#createTaskQuery and TaskQuery#taskParentTaskId and throw an appropriate exception in case the query returns results.
If the solution must be in BPMN, then I don’t see that it becomes much better than what you have. Just replace the signal event by a message event.
Perhaps you should think about your concept user task as really two user tasks; 1 - assess, 2 - complete.
The assess stage has two outcomes, either delegate to get more info and subsequently complete the concept task, or there is sufficient detail to complete the concept task. Hence at this granularity you could model it using ordinary BPMN process flows and an exclusive gate or two.
I suspect that from a user experience perspective you want to combine 1&2 above into a single page flow or even a single form. You could still do this with very basic BPMN flows. Have a form field called status which takes on values something like either ‘escalate’ or ‘complete’. Use a gate to determine which path to take based on the status field. If the escalate path is taken, when complete just re-enter the concept task…
You could use Case Management for the use case you described. You could model a case with one required task (your concept task), one create task-task and an execute task-task (the one the coworker needs to do). As a case can only be (automatically) closed when there are no active tasks and all required tasks are completed, the case can only finish as described in your scenario. Using sentries and disabling manual activation, you could make sure the execute task-task is automatically fired after the create task-task.
