Thank you for the good question.

Link event doesn’t add anything to the process semantic, it’s just a way to represent a process graphically. One can draw a sequence flow from Task3 to the parallel merge on the diagram you refer as well. Both ways will work for this process indeed but in our case we are trying to synchronize different subprocesses. Links won’t help here: a pair of links creates a virtual sequence flow so it’s plain wrong to place them at different process levels or in different processes.

A.B.

“The Condition Expression of a Conditional Start Event MUST NOT refer to the data context or instance attribute of the Process (as the Process
instance has not yet been created). Instead, it MAY refer to static Process attributes and states of entities in the environment. The specification
of mechanisms to access such states is out of scope of the standard.”

So it’s safe to assume that unlike a start event expression, intermediate conditional event expression may refer to the process instance attributes.

Well, I just looked it up in the spec: There is only one instance variable in the spec: “state”. However, you can assign data to a process instance via data input and output, so it’s possible to solve the problem as I state above.

Thank you for valuable input. I like the idea to use conditional event.

The separate pool workaround is artificial indeed but let’s take into account that the whole case is artificial. There is no real need to use subprocesses here hence launching external processes looks like an overkill.

I don’t like the workaround with separate pools, because this is rather artificial if you actually want to model one process. It also adds complexity, since you need to use a correlation mechanism. Communication within the same instance can be accomplished more easily, e.g. by using process variables.

How about this workaround: Use a conditional event instead of the catching signal event. In the upper process you don’t need a throwing event, or you use a none event just to mark the place where the concept reaches the ready state. The actual communication would take place by a flag attribute that is defined in the parent process. Variables defined in the parent process are visible in all sub-processes. “Develop book concept” would set the “concept ready” flag to true, and the conditional event which has waited, would be triggered.

I agree that it would be good to have an attribute in the signal event that could be used for correlating the signal to a specific process instance. Of course, you could define your own attribute using the BPMN extension mechanism. However, this again is an individual extension, but not the standard. I would like to draw a line between such signal events that are bound to a specific instance (maybe a specific type of association). After all, you can draw a line for the message flow so that you can connect the corresponding message events of different processes. The same should be possible for sub-processes (equal rights for sub-processes …!).