When you design a process, you can use message events in connection with the Receive step to interact with a process after the process has started execution. For example, you might want to:
Query the status of a process
Update data or provide control to the process
Based on one or more input parameters that uniquely identify the process, the process engine matches the correlated message events with their intended business process instances.
For example, a purchase ordering process might have an OrderId property. Messages can store the value of OrderId in different parts of the order process using different names and you associate a specific process instance with a unique OrderId. When a message arrives with the correlated OrderId, it is dispatched to the correct process instance. You can create as many correlation sets as you need.
Correlation matches incoming messages with their intended business process instances, so business processes can support asynchronous request/response patterns. (By comparison, synchronous calls need not rely on correlation because the message context is maintained on the stack or across a TCP connection.)
You define message events at the process level. A message event can be either interrupting or non-interrupting.