One of the business processes I'm modelling at the moment includes the following scenario:
A message, type MessageType1, is received by an orchestration, which publishes it via a send port, then listens for a message, type MessageType2, which correlates with the first message using some common attribute. Pretty simply stuff.
The only fly in the ointment is that occassionally messages of MessageType2 will arrive at the receive location without a corresponding MessageType1 match. These messages would normally be suspended, as messages "with no matching subscription", but in our scenario we need to process these 'unmatched' messages using a separate orchestration. This new orchestration therefore has an activate receive shape that subscribes to MessageType2 messages. However, this would pick up every MessageType2 message, including those that are also picked up by the convoy, which we don't want.
A potential solution is to mark the unmatched messages in advance, using some attribute that we can filter by. The problem with this is that the business were not making any distinction between the matched and unmatched messages at the point of creation?
The answer was to go back to the business to better understand why some messages will be correlated, and others won't, which in turn forced the business to look at the process in more depth. This proved to be a very useful lesson for all concerned, and coincidentally helped to clarify a number of other issues with the overall solution.
Another example of the need for a close relationship between BAs and designers at the earliest stages of solution design.