BPMN: What is a Message?

//BPMN: What is a Message?

BPMN: What is a Message?

Message is another fundamental BPMN concept that is not well explained in the spec.  Section 8.3.11 defines a message as “the content of a communication between two Participants

[in a collaboration]”.  As explained last time, “Participants” here means the process on one end and some entity external to the process on the other end.  The message is just the content of the communication, i.e. the information communicated.  The communication itself is a message flow, a dashed connector in the diagram.  In non-executable models, the message flow label is generally taken as the name of the message, a noun.  In executable models, a message icon can be attached to the message flow for purposes of binding the message flow element to a message element in the semantic model, which in turn references an item definition linked to a data structure defining the message content.  Some people use the message icon even in non-executable models, but unless they are referencing some defined data structure there is really no point to it.

You won’t be surprised to learn, however, that there is more to it than that.  Just as a process is not just any sequence of activities that performs work, a message is not just any communication between participants in a collaboration.  In particular, it means different things in executable vs non-executable models.  In executable BPMN, a message is really a system-to-system message related to a service operation, as used in WSDL.  BPMN goes to great pains to stress that “service” does not just mean a SOAP-based web service, but it still means something very much like one.  It still has a set of operations with interfaces defined by input and output messages, for example.  Thus, in executable BPMN, an email is not a message, nor is a fax, letter, or phone call.


In non-executable BPMN, however, human communications between participants is the norm.  How else you would explain things like the diagram above, Figure 7.3 in the spec?  I suppose you could argue that these message flows are “abstract” and don’t strictly represent messages.  But the spec never says that, and it’s more reasonable to say that in a non-executable BPMN the term message means something more general than a communication bound to a service operation input or output.  These message flows seem more like phone calls or emails.

So let’s stick with non-executable BPMN.  You might think that the way an external actor – the Customer, for instance – passes information to the process, or the way one process passes information to another one, is always via some form of message.  The spec pretty much says that.  But it’s not the only way.  In fact, I think it’s not even the most common way.

What does “receiving” a message mean in BPMN?  It depends on the element doing the receiving, the one the message flow arrow points to, such as a Message event.  A Message start event means create a new instance when the message arrives.  A catching Message intermediate event or Receive task means resume a paused flow as soon as the message arrives.  A Message boundary event means initiate some handler action immediately when the message arrives.  A Message event or Receive task is really a flow control object that reacts to an incoming message.  Two things about it are significant: the reaction is immediate and it is unconditional. Receiving a message, then taking time to think about it and decide to maybe act on it or not… that’s not what a Message event or Receive task does.

However, a message flow to a User task or a generic task, as in the diagram above, could conceivably be handled in that way.  But even there, the process is reacting to information pushed to it.  I believe in the real world it is more common for a process activity to pull information from a storage location when it needs it.  BPMN has a way to do that, too, but it doesn’t use a message.  Instead it uses a data store, a global element accessible to both participants.  The external entity or process writes information to the data store, and the process activity – when it needs to do so – queries and retrieves the information from the data store.  This, for instance, is how ordering a song on iTunes works.  You don’t pass your credit card info in the order.  iTunes’ order handling app pulls it from your profile, the data store.  As the customer, you update your profile when you need to, and iTunes processes query it when when they need to.  If you look at the processes in your own organization, I suspect you will find that most of them talk to each other via this shared data mechanism rather than via messages.

The BPMN spec completely ignores this form of integration, however.  In fact, it makes it extra hard to correctly translate it from the diagram to the semantic model.  In the diagram, the connection to a data store is not a message flow – since data store is not allowed to send or receive messages – but a dotted line connector called a data association.  A data association into the data store means a write operation and out of the data store means a read.  For reasons too obscure to contemplate, the data association shape in the diagram does not directly reference the global data store element but a data store reference element within the process.  But if Process 1 is integrating with Process 2 via a data store, which process is that?  Actually, the single data store shape is bound to two different data store reference elements, one inside each process, and both of which point to the same data store global.

What if it’s just the Customer – a black box pool – interacting via a data store, the iTunes example?  Here’s a nasty surprise:  You cannot connect a data association to a black-box pool.  It is not allowed by the BPMN metamodel and schema.  Fortunately, the regular association element looks the same, and you can attach those anywhere.  In this case there would be only one data store reference, with an incoming association and an outgoing data association.  What a mess.

Somebody’s bound to bring up signal, another message-like thing that’s different from a message.  That’s true, but signal has its own problems, and I’ll talk about that another time.



By |2016-12-29T13:40:06-08:00October 11th, 2013|BPMN|12 Comments

About the Author:


  1. Scott Francis October 12, 2013 at 8:23 am

    I like the new look for the site! Also, appreciate that someone is still writing clear concise treatises on BPMN 🙂

    Each time I read one of these posts I find myself comparing to how specific products handle the same issues. For example, Lombardi and IBM have for years allowed for “message” and “signal” events, but the message flows simply aren’t captured in the model. It is a bit of magic to hand off the message to the engine and then assume there will be someone on the other side catching it (or multiple someones as the case may be). From an implementation perspective, it works fine – all the representational / implementation power is there. But from an understanding perspective there’s still a lot that people have to understand without seeing (which is a drawback).

    From working with other tools, there are similar (but different) blind spots in each.

  2. Anatoly Belaychuk October 13, 2013 at 10:59 pm

    Thanks for the post, Bruce. Most people believe that valid representation of automatic email is message while it is a script task.
    Missing data association between blackbox pools and datastores is a shame indeed.

  3. Antonio Caforio October 16, 2013 at 6:48 am

    “What if it’s just the Customer – a black box pool – interacting via a data store, the iTunes example? ”
    Is this not the case for a Conditional Start Event?
    Anyway, in non-executable BPMN I would draw this as a Message Start Event triggered by a message from a Customer. Is that important to have a spec-compliant executable version?

  4. bruce October 16, 2013 at 12:17 pm

    I don’t think Conditional event is appropriate, but that is a subject unto itself, which I will address in a future post. When iTunes initiates the process, I agree it is a message. The use case I mention is when iTunes fulfillment needs to access additional info not in the order message, such as your credit card info or specific device info. If process is pulling that info from customer profile, that is not a message.

  5. bruce October 16, 2013 at 12:20 pm

    BPMS vendors tend to all have a blind spot with regard to entities outside a single process being modeled. This affects, as you say, both the overall business context of the process and the executable implementation. Executable modeling would greatly benefit by inclusion of message flows in the BPMN diagrams. It’s not for lack of encouragement from folks like me and you. Eventually the vendors may come around.

  6. Alexander Roan October 18, 2013 at 11:03 am

    Hi Bruce,

    Thanks for the time and effort you put into your blog and sharing with us. I’m 6 months into working with BPMN (having only a basic knowledge beforehand). I found your iTunes example interesting and I am not personally clear on when to use messages vs. data stores and when using data stores how they interact with data objects (should you use both, or omit data objects when it’s obvious?).

    I took a little time to draw out my interpretation of an iTunes interaction. I’d be really interested in yours and other blog readers comments. I have posted onto my website, but here is a direct link to the image:


    (I had to upload a photo due to security restrictions on the desktop I was using – I realise it’s a bit blurry!).


  7. Nick Broom October 24, 2013 at 7:55 am

    Posted the following on LinkedIn as well, but thought I’d go belt and braces…..

    The point that piqued my interest greatly was around the typical interaction between human participants and that they react more to pulls from data stores that messages.

    The scenario I have at the moment is that Person A will submit a request via email to a shared mailbox. Person B is tasked on a given day with monitoring that mailbox and then processing the requests that are received. Those requests may be prioritised where there is more than one, based on certain criteria.

    So far, I have been modelling this as two separate pools. The first results in a ‘write’ to a shared data store representing the mailbox. The second is timer triggered, where the timer is named ‘Periodic mailbox check’. The first activity after this event ‘reads’ from the mailbox and is a looping task called ‘Identify requests’. This is followed by a gateway that assesses whether at least one request has been found. If not, the process ends until the next periodic check. If it does find at least one, then they are prioritised and processed in order of priority, using a looping task.

    Is this an acceptable way of modelling it? An alternative I’d toyed with was having each request arrive as a message, but the article says that a start message event implies instantaneous initiation of the process, not a ‘wait-and-see’. In addition, I couldn’t think of a way to represent how I might prioritise the mails.

    This is a pretty common approach across many businesses, so someone must have established an acceptable pattern?



  8. Cristian December 8, 2013 at 1:53 pm

    Hi there,

    Could you, please, express your opinion on whether a message event may be used in a non-automated process execution, ie no process engine?

    Thank you.

  9. bruce January 9, 2014 at 9:52 am

    Yes, message event is very commonly used in non-automated process, where a message refers to any type of unidirectional communication between the event and external entity. In executable BPMN, a message has a narrower meaning of an automated system-to-system message sent or received directly by the process engine (i.e. not by some other resource in the process; e.g. automated email usually implemented as service task not send task). At least this is my interpretation.

  10. Cristian February 5, 2014 at 3:04 am

    Thank you so much. I had numerous interactions with Anatoly Belaychook on his site about this topic, under the blog entry ‘Robots don’t talk to humans’ – http://mainthing.ru/item/602/

  11. Performance Management Systems February 12, 2014 at 10:15 pm

    The first goal of BPMN is to provide a notation that is readily understandable by all business users. This includes the business analysts that create the initial drafts of the processes to the technical developers responsible for implementing the technology that will perform those processes.