I’m a bit puzzled here with the non interrupting IE. Why should I need this? I see two main cases out of the situation given by Bruce.
First case is when you have small processes running in parallel of your main one. Those Processes are triggered by external event and are executed according to your main process status. I model those with Start event of type multiple (a message and a rule). An example could be when receiving a message from the customer while waiting for a credit answer we should send him a small notification that we are wating for the credit.

The second case I see, is where i’m differentiating the coin level. Process A is running at Order level while the exception process is taking care of one line of that order. I would not allow this in my process as we are not speaking about the same coin rolling in my process model.

IMHO, non interrupting IE don’t help me much and could be an open door for wrong modelling.

Thanks and have a nice day
Patrice

I’m glad to see that you’re updating the blog again!

With respect to non-aborting intermediate events, this is a construct that Teamworks supports now and is something that I absolutely agree should be added to the BPMN spec. Clearly it makes your example diagram above quite a bit more readable than the “spec compliant” version that utilizes a subprocess and a gateway.

To me, I don’t even think you need another icon to indicate this behavior for attached events–I usually indicate that in either the name of the event or the label on the exception flow coming out of it. That kills two birds with one stone: the diagram stays uncluttered yet it still conveys the full meaning of the process to the reader.