Bruce Silver shared his thoughts about the conditional event in the recent post.

For those not deeply immersed into BPMN 2.0, the conditional event pauses a process until specified logical expression becomes true (changes its value from false to true, to be precise). I’m writing this post in October, so the good conditional start example would be:

Fig. 1. Conditional start event example.

Here the process starts when the logical expression becomes true, i.e. when winter comes. (BTW, this is the real rule in effect here in Moscow.)

The typical conditional intermediate example:

Fig. 2. Conditional intermediate event example.

Here the process waits until the invoice record stored in some unspecified system would be marked as paid. (This is overly simplistic version - please be patient, the more robust will follow.)

Bruce says that he prefers not to use conditional events and excluded it from the “Method and Style” - the collection of best practices he created, supports and promotes by his famous book (the best BPMN guide in my opinion).

With all respect to Bruce as my BPMN teacher, I have a different opinion on the matter: I believe that conditional event is the best solution for certain quite common process collaboration scenarios. (To be more specific, it’s the conditional intermediate event; the conditional start event doesn’t have much value so it won’t be discussed here.)

We’ll start from modeling for automation scenarios and consider pure analytical modeling afterwards.

Bruce provides the following arguments:

1. The conditional intermediate event based on the process data is excessive in most cases because it can be replaced by a gateway which is more intuitive and hence should be preferred.
2. For Conditional event to be useful, it must refer to some data in the environment beyond the process data. However, the BPMN specification leaves the mechanism to access this data our of scope. Bruce interprets “out of scope” as magic and magic should be avoided in any sound methodology indeed.
3. The datastore updates could be used to trigger the Conditional event yet such an update must be caused by a data association from within the process, not externally - “at least on the Trisotech platform”.

While I fully agree with the first statement, the argument about magic looks dubious. I believe it’s the basic BPMN assumption that 1) there is some data environment beyond the process (transactional) data; 2) the process data is linked to the entities in this environment somehow (e.g. by database foreign keys, global identifiers, webservice business keys etc.) and 3) there is some mechanism to obtain these data (e.g. by SQL select or oData call).There is no need to explain it in each section of BPMN standard so I prefer to treat “the specification of mechanisms is out of scope of the standard” as “use a mechanism at hand”.

The third argument is more about specific tool than modeling logic. It’s true that current BPMN modeling tools aren’t very good in dealing with conditional event. What I’d expect from any BPMN modeler vendor is the ability to draw data flow from a datastore like at this drawing made in Visio:

Fig. 3. Conditional event triggered by datastore update.

However, it didn’t happen yet. The popular modeler Bizagi Modeler doesn’t allow data flows connections to conditional event at all. Another popular tool bpmn.io reverses the data flow direction:

Fig. 4. Conditional event representation in bpmn.io modeler (wrong).

As a side note, most BPMN modelers also don’t allow to connect a dataflow to a “black box” pool boundary like shown at fig. 11 below.

Now let me show the value of the conditional intermediate event. Let us consider the business scenario similar to the one used by Bruce:

1. Customer submit a service request.
2. Request is evaluated by the manager and if accepted the invoice is created and sent to the customer.
3. If the payment happens until the invoice due date the process continues to delivery, otherwise the process ends.
4. Now the most interesting part: the customer is supposed to make a payment by a bank transfer. Our financial department runs the bank software on the regular basis (e.g. twice a day) to obtain the statement containing ingoing and outgoing transactions, line by line - this is how our company becomes informed about customer’s payment.

It’s obvious from the synopsis above that there are two processes: one dealing with the customer’s order and the other processing the bank statement. These processes should communicate to each other somehow. Let’s consider three basic mechanisms - messages, signals and conditional event - and some variations.

Collaboration via message event

This is the most popular approach and the only one novice BPMN authors are aware of.

Fig. 5. Collaboration via message event.

I hope that the diagram is self-explaining except the “Get invoice id” task. If the message flow destination is an intermediate event (like in this case), one needs to aim it not just to the process shown as connected at the diagram but to exact process instance. This is done by so called correlations in BPMN and the invoice id is a good candidate for this role. Here is how it works: the bank statement process extracts the invoice id from the current transaction data and sends the message to the customer order process that issued the invoice with this id.

This algorithm isn’t very robust because customer may not specify the invoice id (and customers do miss it quite often in reality). In this case the payment usually can be matched to the invoice by the customer name / tax id and payment amount. To implement this more advanced logic, the bank statement process needs the information about the invoices which means the collaboration via shared data:

Fig. 6. Collaboration via message event and shared data.

The “Invoice issued” datastore can be implemented e.g. by a database table containing all the attributes that may be useful in identifying the invoice by the bank transaction (invoice no, customer name, order no, amount etc.) plus the order process instance id to serve as correlation.

Collaboration via signal event

Fig. 7. Collaboration via signal event (wrong).

Using signal event instead of message is a bad idea, really. The scheme above would work only if there isn’t more than one order awaiting payment at any given time. Otherwise, the signal initiated by the bank statement process will trigger all such order process instances.

Collaboration via conditional event

Fig. 8. Collaboration via conditional event.

The central role is played by the datastore “Invoices issued”. It can be implemented e.g. by a DB table having the same name.

Once the customer’s order is accepted and the invoice created, a new DB record is created and filled with such data as invoice no, customer name, order no, amount plus the attribute named “status”. The conditional event further on the process flow watches the value of this attribute. As soon as it becomes “paid”, the process continues to service provisioning.

The bank statement process uses this DB table to identify the transaction first and then, if successful, to set the value of status attribute as “paid” which triggers the order process.

The diagram at fig. 8 isn’t better than the one at fig. 6 at first glance. To feel the difference let’s consider more realistic scenarios. Let’s assume that our company has several lines of business, each selling its products and services by following its own specific selling process. Now the bank statement process will need to figure out which the process to notify about payment by a message:

Fig. 9. Multiple messages.

This is no good from architectural point of view: why should the bank statement processing process ever care about the internals of customer processes? If another business line would arise once a day, why should we change the bank statement process?

This is in fact the fundamental problem of messages: it creates tight coupling between processes. One cannot just fire a message but needs to specify the exact process and process element as a message destination.

Signal and conditional event, by contrast, creates loose coupling: collaborating processes don’t need to know about each other’s existence leaving alone internals. In case of signal they connect via signal name, in case of conditional event communicating processes only need to know about the datastore serving as an interface.

Fig. 10. The throwing part of collaboration.

Fig. 11. The catching part of collaboration.

We can further elaborate our example by assuming that there are several “throwing” processes too. This would be the case if we provide payment methods other than bank transfer. This complication won’t do no harm: the datastore will remain the only communication point that each process is aware of.

Non-executable models

The discussion above was about executable BPMN models, i.e those powered by a process engine.

Regarding non-executable models Bruce notes that they do not define process data. Since conditional event deals with data by definition, it should be avoided in such models.

I agree with this recommendation albeit on the different reason: I prefer to avoid all events except None and Timer if there is no BPMN engine behind the model. Human performers either don’t understand what exactly they should do when hitting say a signal on a diagram or treat them wrong (mostly the case with message events).

I have explained before that conditional intermediate event can be implemented by the combination of gateway and timer. Here is how it mak look:

Fig. 12. Non-executable model: conditional event replaced by task, gateway and timer.

The “Invoices issued” datastore can be implemented in many ways ranging from SAP to shared Excel file or a Kanban board.

Fig. 13. Kanban board example.

Conclusions

1. Process collaboration via conditional event should be preferred over messaging because it provides loosely coupled process architecture.
2. BPMN tools vendors should allow dataflows from datastores (and data objects) to conditional events to depict the data that triggers the event.