Question about BPMN: How signals are propagated inside a pool?

Hello all,

I have created a test process to examine how signals work, but I cannot understand the following behavior that I receive when I create a new process instance.

I have something like the following:
(tokens are marked with green, while matching signals have the same letter)

I can not understand why I see 9 tokens in the right event-subprocess. I would expect to see only one.

The logic is that a token starts in TEST1 pool and once arrives at the throwing signal event “A”, the signal is catched in the event-subprocess as a non-interrupting signal start event. Inside the subprocess, a new signal is thrown “B”, which is catched in another event-subprocess.

However, I would expect to see only one token and not 9.

Any ideas why this happen? Is it something that I am missing because of BPMN 2.0 specification or is it something because of Camunda ?

Thank you in advance.

Upload you process model.

diagram_3.bpmn (8.2 KB)
Here is it Niall. Very simple, but I hope you can understand the logic.

Thank you.


I have just tried your process on a clean Camunda 7.14 and started a single process instance from the Task List app. I get this:

Just a thought - signal events are global - could you have another process that (also) fires Test2 signals?



I think the problem is likely with what @mimaom pointed out.
Single events will trigger not only signals in the pool that they are fired from but any signal listening in all instances of all processes. Signal is a broadcast.

What probably happened here is that you’re run this process more than once. Each time creating a single instance but each instance triggering each other instance.


@Niall @mimaom

Thanks for your updates.

Do you have any suggestions what should I use to trigger events only for specific instances?
I guess message events could serve that way, but according to BPMN 2.0 specification they are tailored to communicating messages between EXTERNAL participants.
So, in this case, I guess its not correct, since I have one pool.

Any thoughts?

Indeed, you’re correct message events would not be a good idea here.
By far the easiest approach would be to use a non-interrupting conditional event - it would be triggered simply by setting a variable and is only scoped to the process instance.

Are the escalation events a good solution?
Are they used only for communicating subprocesses with parent processes?

For sure, you could use escalation as well - escalation add the additional feature that if is not caught in the process that threw it, it is then propagated to the parent process, so it has a bigger scope than a conditional event which will never leave the instance.

1 Like

Thanks Niall!