"camunda" wrote : Agreed. But in reality in your project, what do think the people do? Build a (complicated) correlation mechanism or hack an action which enables the SIgnalCommand again? ;-) It is our intention to provide some support for this but, as always, there are other issues to be addressed. "camunda" wrote : But you could have to process flows in parallel, both communicating with the ESB or maybe both flows even communicate with an external partner. Only the token id is unambiguous in this case. In the projects I know I always was fine with the token id. But in this case the communication would initially be driven by the jBPM process and, as such, the correlation mechanism would again be relevant. You would still need to handle instances where the token had moved forward and/or looped and the token id is not sufficient for this. "camunda" wrote : BTW: Where is the problem with a loop? That doesn't change anything with the token id. Only Fork/Join does... It doesn't change the token id but it can change the request being made. As such any corresponding responses should be matched up. quote="camunda"]Don't worry ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200131#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...