How to create parallel workflows?

[manuelmuehlig-HRI-EU]

Hi,

I am desperately trying to model a workflow for Imixs-Office-Workflow that contains parallel tasks. For example, a requestor triggers three tasks for three different teams that can be worked on in parallel. After the three teams are done the requestor should get feedback and continue with his process.

I have no idea how to model it for Imixs-Office-Workflow since it seems that parallel gateways do not work. Is the SplitAndJoin plugin the correct tool to use? Is there a minimal example of how to do such a split and join?

Thanks,
Manuel

[rsoika]

Hi @manuelmuehlig-HRI-EU , yes the SplitAndJoinPlugin would be the right choice for your requirement. It will duplicate the current workitem and continue the workflow in a separate branch of your model or in a complete different workflow group or model. The Plugin allows you to specify which data (items) should be copied into the sub-workflow.

And this is the important part of this kind of requirements. If you really plan to split the process instance into separate 'parallel' instances you need to take care which data is controlled by which user. You would typically need separate forms with different input fields avoiding that one user overwrites the data form the other. This is why we recommend to split into a different workflow group as explained on the SplitAndJoinPlugin Page .The SplitAndJoinPlugin allows you also to write back data into the main process instance.

On the other hand the ParallelGateway will create a complete new Version of your current process instance. This is not useful to work in parallel. It is more used to freeze/archive the current processing status into a locked instance. For example for later revisions.

But if you just plan to do a kind of parallel approval process, than no Split is needed. In this case you can also forward the task to 3 different approvers. They all are allowed to update the data and approve the instance. In case two users really work in parallel at the same time, Imixs-Office-Workflow will detect this and inform the later user. To avoid this you can model a Check-Out/Check-In mechanism. But this is only necessary in rare cases.

So also take a look at the ApproverPlugin which is a powerful feature to ensure that a group of users has approved a task. Let me know if this answers your question.

[manuelmuehlig-HRI-EU]

Thanks for the very fast and detailed answer. Can I ask a followup question?

I think the ApproverPlugin is not what I am looking for, since it is not about approving something, but more about three different teams do something and provide different information back to the requestor.

For the SplitAndJoin plugin, how can I split a process into three, not only two processes? Further, how can I assign the different resulting flows to different teams? I assume by having a event at the beginning of each follow-up flow with an appropriate <item name="space">TEAM_NAME</item> entry?

[manuelmuehlig-HRI-EU]

Sorry, I just saw I could specify multiple split directives. I will try that now.

[rsoika]

Yes, exactly. I have created a example model so you can see and test the details of this concept:

In this example the plugin copies the value of the field debug.city, so you can see how it behaves. When the last sub-task is completed, its debug.city value will be pushed back into the main task.

Working with a sub workflowgroup gives you more flexiblity in modeling the details and form elements. Also Imixs-Office-Workflow automatically list all subtasks in the history:

Thus, the entire process is transparent from the user's point of view.

[manuelmuehlig-HRI-EU]

Wow, thank you very much. This helps a lot.
Especially the example will be helpful for others as well. Maybe best reference it in the SplitAndJoin documentation.

[manuelmuehlig-HRI-EU]

Ok, I played around with your model file, but one issue remains for me.
I change the "space" in the [init] event of Debug-Sub by <item name="space">EGN</item>. "EGN" is a team that I have.
Then I also had to change a few permissions, so that only the team can work on the sub task and not the owner. For transferring back the information I also had to change the permissions in "Task-1" so that the current Bearbeiter can write. Otherwise there was an error with missing permissions.

However now the problem is: When I do not have the switch to another team, origin_update() works fine. It copies debug.city as expected. However with a team switch I just cannot get the data back to the origin process. I attached my changes here.

debug-parallel-de-1.0.0.bpmn.txt

[rsoika]

Yes, the problem is that the user form the sub-task has no write-permission. You can possibly extend the write access of the main task to all users involved in this process.

The question is if a user from the sub task should have the right to update the main task. I guess this is not the case in your situation?

One solution would be to work with Async Events. This event type is executed asynchronous from the workflow manager itself - so it runs with manager access and is able to update the task.