In my previous post I did a favor to BPMN messages fans by including these elements into human-powered palette. Frankly, I’d recommend to leave them off because in too many cases people use message events excessively and incorrectly, like in the example below:
Dangerous! Do not try this at home.
People that use just tasks, gateways and control flows, tend to create more straightforward and more comprehensible diagrams than those who are aware of BPMN messages and message elements. BPMN message events/tasks are similar to automatic tasks: they are for process engines and aren’t supposed to be executed by a human.
The most common misunderstanding is associating the envelope icon with email. A human task should be utilized to model sending an email in human-powered environment; if the process is BPMS-powered then script task is the best option:
|Wrong: email via messages||Right: email via human task
|Right: email via script task
If one just wants to depict that a certain task communicates with some external entity (e.g. customer or supplier) then black box pools and message flows attached directly to the task may be an option:
Better yet, keep the diagram clear from message flows and black box pools. If the task is labelled “Get customer’s commitment” then it’s pretty clear that it communicates with the customer, no need to clutter the diagram:
There is only one case when black boxes and messages are essential: if one needs to depict ALL the messages going to/from the external entity in order to visualize the complete “communication contract” with the said entity.
The final note about message events vs. message tasks: their primary functions are identical. The subtle differences are those between events and tasks in general: unlike events, tasks may carry attached events (e.g. timers) and/or modifiers (e.g. mutli-instance) which is handy sometimes: