Using element variable (multi instance) in expression in a form

I have a service task that outputs a java.util.ArrayList<string>. I would like to create a user task for each item in that array. The user task should have a form in which the corresponding item is referenced. I have included a screenshot of my failed attempt below.

Suppose that items = ["A", "B", "C"]
This does indeed create 3 tasks: “Form: A”, “Form: B”, “Form: C”.
So far so good.
However, when I open any of the three forms, the expression within the form always evaluates to “C” (the last item in the array). Why does this happen? And how can I prevent this?

Note that everything works as expected if I use multi-instance type ‘sequential’ instead of ‘parallel’, but this is not an option because I would like to start all tasks at the same time.


I couldn’t include a screenshot of the form as new users are only allowed to use one image. The form only has one expression: ${ item }.

im also looking for a solution for this problem. as above mentioned i get same value for Element variable for all multi instances when i choose sequential false(parallel). can anyone suggest a solution to get element variable values in collection for each instance.


Following example could help you:


Any luck on this I am facing the same issue

Here is the related bug:

Is this fixed? I’m learning Flowable and created a subprocess using multi-instance as shown in the screenshot. The decision task outputs a variable depending on a field of the element in the input list, which will be in turned used to create a user task with a form to show. This works fine if the the multi-instance is sequential, but once it’s changed to parallel, all the tasks get the last variable created by the decision task. How should I solve this? Thanks.

Which version of Flowable are you using? 6.5.0 was released in the last couple of days and should resolve this.

It appears that decision tables are putting their output values on the overall process and therefore overwriting each other on each execution. I’ve opened a bug for it. This is slightly different, but related to the previous issue.