Looping and conditions

This may have to do with the sequence of processing and could potentially be correct indeed. But it's hard to tell from a screenshot.

Imagine, the processing enters the loop and gets to the junction item. There is looks for its successors and finds 2 of them. One goes up, the other goes right. If it goes right first, it remains in the loop and gets to the same junction again. There is goes right again and still remains in the loop to get back to the junction. This is happening as long as loop goes.

When it's done with the loop, then it goes back in the execution stack to the point where it found more than one successor, and starts processing the remaining ones. The processing then goes back in the stack until all remaining successors have been processed.

That could explain the behaviour you described. If that assumption is correct, you need to change the sequence in which it finds the successors at the junction. Usually, BPMN.io returns the successors in the order they have been created. But it does not provide any visual indicator of the sequence, unfortunately. However, that's not an implementation issue, that doesn't even seem to exist in the BPMN standard in the first place, interesting enough.

To verify that assumption, you could follow the debug log and verify there, in which order the successors get processed.

Hello Jürgen!

Thanks for your info. It was indeed helpful and now it works.

I guess I was wrong in assuming the display action reading starting with "checkpoint: loadedProfile" (see loopScreenshot) is going to get called with every loop run. Instead, it only gets fired once. There was no condition check before (other than the list item >0 count at the beginning of the loop).

the screenshot (loopDisplayWithinLoop) shows the output difference when display action is within loop (sequentially and not parallel).