Optional Tasks in BPMN and other modelling issues

Me and my team are working on a process in BPMN with some tricky situations:

  • Tasks can be executed in parallel
  • A task to finish the process can be executed at any time
  • There is an optional task which affects the flow

We came up with the following workflow, which seems most logical to us:

When the Booking Con task is completed, Camunda shows 4 new tasks:

  • Close Dossier
  • Select Vessel Operator
  • Send Quotation Request
  • Select Transporter

This is exactly what we want, so that is good.

However, we want that when the Close Dossier task is completed that all other tasks are no longer available.

Same goes for the Select Transporter Task, where the Send Quotation Request Task is optional beforehand. We tried placing the Send Quotation Request after an exclusive gateway, but then we would need to know beforehand whether the user is going to send a quotation request. We know whether the user needs this option when either:

  • The user completed the Select Transporter task, meaning that any instance of Send Quotation Request can be ignored.
  • The user completed the Send Quotation Request task, meaning that we will proceed to Select Transporter.

We thought of a workaround where we remove all instances of previous tasks which happen before the current task. E.g. when starting a new workflow:

  • Booking con completed, no previous tasks, nothing happens.
  • Select Vessel Operator, has previous task Booking Con, cancel any running task instances of Booking Con.
  • Select Transporter, has 2 previous tasks. Cancel any running task instances of Booking Con and Send Quotation Request.

Although this should solve our problem, we would like to know if there is a better way to model our situation. Since it would be nicer to solve this issue in the model.

Any advice is welcome. Thank you in advance :slight_smile:


This would be a great example for CMMN…

One way to cancel your optional tasks is to use a nested scope with a terminate end event. The terminate will remove all tasks in its scope. Its a bit of a brute force approach, but works. Hopefully you can get a sense of designing your process model as a finite state machine where states can be modelled as scopes or inline sub-processes. Hence by thinking of your model as a state machine, you can transition between various valid configurations…

Also, given the close dossier must occur, notice how I have modelled to enter it just once…





Use ebbeded event sub process

I managed to solve the issue by using the embedded sub processes. Thank you for the suggestion, works like a charm!

For anyone if interested: The diagram now looks like this: