Hi @Nele ,
Thanks for the response. Yes, we’re modelling a process that can be worked on in a long period of time. At some point there is an end, which we modelled with an event. I took some time to experiment with the ideas that you suggested. Here’s a process that should work, but has some issues:
The main issue is that once an event is received, tasks in the subprocesses are deleted and recreated, even if the state ultimately remains the same. So my main question is what recommendation would you give for “data-driven” tasks, whose resolving depends on data in the context/events. Is the user task even a proper building block to be used?
As a workaround, a colleague of mine pokes around with the history/events API, in hope that we can treat delete + create of the same task as a whole (basically an update). However, with this modelling sometimes a delete of a task is semantically equivalent to that task being resolved (in case the data in the ItemModified leads to a different path in the gateway), and sometimes - it’s a regular delete. Could you or others shed some light onto the topic?
Kind regards,
Milan