Environment (Required on creation):

v7.12.8-ee

Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket):

Having an activity (in my case a "Send Task" service task) that is multi-instance based on a collection,  the engine seems to fail to do input mapping that uses the declared element variable as part of resolving the local input for the task.

This mapping seems to work for multi instance call activities and multi instance expanded sub-processes. 

Steps to reproduce (Required on creation):

Define any executable bpmn that contains a multi-instance parallel message throw task.

Assign a collection for the multi instance handling.

Choose a name for the "Element Variable"

Use the element variable in the input mapping as an expression.

Try to run the flow.

I have attached a simplified model from what we use in the system - see "Input_Mapping_Not_Working_On_ElementVariable.bpmn".

In here, you will notice that I have a parallel multi-instance send message, with collection set to "${Policies}", and Element Variable set to "Policy".

Then, on the input/output, I have declared an input parameter "ProductType" which should resolve the value from ${Policy.productType}  (note: "Policy" is the Element Variable from the General tab, and productType is something I expect to be inside the object).

I have also attached another BPMN which is actually a working one, with the workaround we did in our system to avoid the bug. See "Input_Mapping_Workaround.bpmn" in the attachments, where you will notice that I insterted a multi-instance expanded sub-process in the flow, and moved there exactly the same declaration of collection and element variable and input mapping.  And converted the message throw activity to a single instance one (since the expanded sub-process resolves the elements one by one).  This solution is working, but it simply looks ugly, and it is unclear why it was modelled like that without having knowledge of the bug.

We also know from our system that call activities are also handling this correctly - but in this case we wanted to make it visible that we do a message throw, and a call activity would have hidden (visually) that detail.

Observed Behavior (Required on creation):

Getting an exception looking like this:
org.camunda.bpm.engine.ProcessEngineException: Unknown property used in expression: ${Policy.productType}. Cause: Cannot resolve identifier 'Policy'

Note: A more detailed stack trace is added as attatchment

Expected behavior (Required on creation):

I expect this to not fail, and actually handle the input mapping for my iteration element.

Root Cause (Required on prioritization):

Looks to me like the evaluation of the input mapping is happening prior to resolving element variable. This does not happen in case of call activities or sub-process events.
I do not know for sure if this happens for other types of tasks, but it definitely happens for message throw activities. 

Solution Ideas (Optional):

Make sure the element variable is resolved prior to handling input mappings in case of multi-instance activities, in a way that is consistent with call activity handling

Hints (Optional):