Which elements of BPMN leads to creation of new Execution_ID

[nikki]

Hello Together,
by analyzing the data from history tables, I am wondering how execution EXECUTION_ID_ 's are generated. I found the following cases:
flow of several tasks: PROC_INST_ID_ = EXECUTION_ID_
splitting AND: for every token the PROC_INST_ID_ is kept and a new EXECUTION_ID_ is generated.
splitting XOR: the task which is not executed gets the same EXECUTION_ID_ as the PROC_INST_ID_ additionally the row of the not executed task has a start and a endtime (Why is that?)
the task which is executed gets a new EXECUTION_ID_
intermediate timer-event: a new  EXECUTION_ID_ is generated for the task

Is this right?
And do there exist more elements (except of gateways) which produce new EXECUTION_ID_?

Thank you, for your help!
greets Nikki

[jbarrez]

Executions are created every time concurrency is needed, or when a scope is created (a scope= activity + timer, an embedded subprocess, etc.)

flow of several tasks: PROC_INST_ID_ = EXECUTION_ID_

Only if the process doesnt have concurrency or scopes.

splitting AND: for every token the PROC_INST_ID_ is kept and a new EXECUTION_ID_ is generated.

correct. For each outgoing sequence flow, an execution is created. These are merged again in a converging parallel gateway.

splitting XOR: the task which is not executed gets the same EXECUTION_ID_ as the PROC_INST_ID_ additionally the row of the not executed task has a start and a endtime (Why is that?)

Could you elaborate that with an example, I'm not quite following here.

intermediate timer-event: a new EXECUTION_ID_ is generated for the task

Yes, because that is a new scope (for the timer)

And do there exist more elements (except of gateways) which produce new EXECUTION_ID_?

Multi instance (new in 5.3) does some serious execution juggling.