When to use message events?

Frank,

You are absolutely correct when you are using messages between pools (which most likely represent other processes) you have to use message flows. ARIS will not allow you to create a regular, non-dashed connection between pools.  According to the spec, you can model multiple "flavors" of messages:

• from a function in one pool to another function in a second pool,
• from a function in one pool to another pool (black box)
• from a function to a catching message event / from a throwing message event to a function
• from a catching to a throwing message event
• from pool to pool
• in choreography and conversation diagrams

Semantically it is also the same if you have a construct like "function > message event" or "function > send function" - the later only makes it more obvious that someone does something and sending is an activity. Remember, events are no activities, but only "something that happens" - the activity is always in the function.

It is also your choice if you want to include a message symbol (envelope) or not or if you want to add a connection description or not, even though I recommend that you find a standard modeling style in your project, so that the models are visually comparable.

Please have a look at the graphic below for some examples of message flows.

Thanks for your helpful answer!

The inflation of modeling a message relationship might be something we want to add to our collection of BPMN best practices. What do you think? What would be your recommendation how to do it?

Apart from the syntactical constraints mentioned above by Roland Woldt, I have this feeling now after modelling a couple of internal business processes:

• Between different pools, the transition between processes should usually be by way of a message event (meaning, not implicitly by just drawing a dashed line between associated activities).
• if the starting activity itself describes/contains the compilation of the message (e.g. "Inform participants", "Send flight booking"), then the throwing message event can be left away.
• the same applies for the target activity and the catching message event.
• the message event should always be used when a real email communication is meant to happen. Hinting at this implicitly (by drawing only dashed lines between associated activities) is a semantic loss.
• Always describing throwing/catching message events in the process diagram also has the advantage of showing off 'optimizable' process flows, because message transitions appear to me to be clearly a good starting point for optimizing a process, and the inflation of message events is going to indicate this visually.

Let me know if you have further comments/opinions.

I like it :-)

ARIS allows exchange of data objects between pools. I can't remember if the specification allows it but I kind of like it. In which case would you use data objects which is an output from an activity belonging to one pool that is an input to an activity belonging to another pool? Let's have two examples:

1) A company receives an RFP from a prospect and returns a Proposal

2) A system integrator gets some application packages produced by a subcontractor and includes them in a system module delivered to a client

BPMN doesn't allow the usage of standard data objects for the exchange between pools, but only the message object (which is an information carrier in ARIS). Funny enough, the spec also uses this object for the exchange of physical goods ... as chapter 7.1 says - BPMN is not meant for data modeling.

Thanks for the graphic!