For the convinience of my English-speaking readers I’ll translate the most popular posts here, like this one.

Typical BPMN use cases are:

1. create a process-based operations manual (let’s call this “analogue” process modeling)
2. create a BPMS-executable model (let’s call this “digital” process modeling)
3. create process-based software requirements for application developers

Let’s define the analogue/digital divide first and then proceed to use case #3.

• Analogue process is performed by human participants following standard operations procedures manual or some othe document usually combining process diagrams with text instructions. Performers may leverage various tools ranging from phone and desktop calculator to SAP terminal; what’s importaing is that a process performer is responsible not only for completing the assigned tasks but also for transfering the responsibility to the next participant. BPMN is good in depicting who is responsible for what and at what points of the process the “relay baton” is passed.

Fig. 1. Analogue process example

• Digital process execution is controlled by so-called “process engine” - specialized software that tracks the process status, assigns tasks to human performers and makes API calls to various corporate applications functions and/or online services according to the BPMN process model. A process model that a process engine is able to read and follow is called “executable”. In this scenario a human participant is only responsible for completing assigned tasks while the process engine controls the transfer of responsibility. From the participant’s point of view, tasks appear out of nowhere and disappear to nowhere after completion while in fact the process engine immediately assigns the next task to the appropriate performer as soon as the current task is completed.

Fig. 2. Digital process example

It is sometimes argued that BPMN is invented for digital processes only but this is an exaggeration.

The true statement is that many BPMN elements only make sense in a digital processes. E.g.:

• Script and service tasks assume no human performer and therefore are inapropriate for analogue process - there is no one to run them.
• Message event, send and receive tasks, error event, escalation, compensation, etc. are also more suitable for programming an automatic process than for depicting human performers’ activities.

These two different BPMN applications utilize different subsets of BPMN palette so I recommend to make it clear before starting a modeling excercise: are we dealing with a digital process or analogue one? If it’s an analogue process then one should use the reduced BPMN palette that includes user task, two or three types gateways, subprocesses, multi-instance loops, timer, terminator, lanes, data objects and data stores, annotations. You may be surprised how much can be done with such a limited set of elements, if used wisely.

Otherwise - in the case of a digital process - one may use complete BPMN palette including messages, conditional events, errors, escalations and others.

Outside view of the application - user’s perspective

Computer applications are usually considered as a “black box” both in analogue and digital business processes: user presses a button, some magic occurs in the application and voila - the money are transferred between customer’s deposit and credit card or a product is reserved for sale in the warehouse database. It is assumed that business is always done by people and whatever tools they may use - a phone, paper and pencil, a spreadsheet or an ERP system - they are just tools.

Let’s consider receiving goods delivered by supplier as an example. The simplified process comprises three tasks triggered by the supplier’s truck arriving to the warehouse gate:

Fig. 3. Receiving goods at the warehouse, outside view

One may add a custom annotation to specify the computer application used:

Fig. 4. Custom annotation

Inside view of the application - developer’s perspective

Now let’s consider the third BPMN use case scenario: process automation. Let’s suppose that we are in charge of designing and developing the warehouse application.

The common “black box” approach would be inapropriate if the application does not yet exist or if we are going to redesign it. In this case we must not only explain process performers where to use the application but also explain to the developers what the application should do.

The common - naive - approach is to show the activities performed by the human and by the application in a sequence:

Fig. 5. Receiving goods at the warehouse, combined outside/inside view

Here we have used the lane to depict activities performed by the application. It’s pretty legal - lanes in BPMN may be used for everything but external participants.

Digital subprocess within analogue process

I’m not comfortable with the diagram depicted in Fig. 5 because it assumes that the process is digital since there are service tasks. But what if there is no process engine to execute the sequence of human and serivce tasks?

I’d recommend the two-layer approach:

• the outer (process) layer presents end-to-end logic
• the inner (subprocess) layer presents application internals

Fig. 6. Layered process

Here the “Goods receipt processing” is implemented as a reusable process invoked from the “Goods acceptance” end-to-end process via call activity.

Conclusions

1. Use the reduced BPMN palette if there is no process engine to execute the process.
2. Depict the computer application via lanes and/or custom annotations.
3. Use script and service tasks performed by an application internally only if you are (re)designing it.
4. Use subprocesses to integrate application internals into end-to-end process logic.

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.

Please compare:

1) Table 10.89 at p. 250 says:

The None Intermediate Event is only valid in normal flow, i.e., it MAY NOT be used on the boundary of an Activity. Although there is no specific trigger for this Event, it is defined as throw Event. It is used for modeling methodologies that use Events to indicate some change of state in the Process.

2) Table 10.93 at p. 259 also clearly shows that None intermediate is a Throw event.

3) However the text at p. 271 says the opposite:

There are three (3) variations of None Events: a Start Event, a catch Intermediate Event, and an End Event

Here is what other authoritative sources say -

4) Bruce Silver, “BPMN Method & Style”:

Omission of eventDefinition signifies a throwing None event, which is allowed; it can be used in the diagram to indicate a particular state of the instance.

5) Tibco:

Intermediate None event indicates an unspecified change in the process.

6) Camunda:

Intermediate none events (throwing) can be used to indicate some state achieved in the process.

Looks like the text at p.271 should be corrected to -

There are three (3) variations of None Events: a Start Event, a throw Intermediate Event, and an End Event

PS. Thanks to my colleague Julia Wagner for pointing to this issue.

UPDATE: Bruce Silver’s comment -

Anatoly, Yes I agree with your post - (3) is incorrect, along with 400 other errors reported since 2009.

The diagrams are valid but here is the caveat: server should know the client internals - namely the event on the client side. It’s ok if the server deals with a single client but what if not?

Let’s consider the example: sales process bills the customer and proceed to wait until another process that polls the bank on timely basis would send the message that the bill is paid -

Now let’s complicate the case: let’s assume that there are several sales processes: one for goods, another for services, yet another to VIP customers, and via partner etc., the list of process templates is open. Where should the server route the message?

Here is the solution: conditional event instead of message -

1. Client process (Sale) writes the task to DB and proceed to wait for the desired task status (bill status = paid).
2. Server process (Incoming payments) changes the bill status.
3. Client process awakens and proceed.

Neither client nor server don’t know each other’s internals, collaborating exclusively via common data (bill). It gives developers freedom to change any process scheme without affecting the others. Or to add another client process variant. Or server variant.

A separate question is whether your favourite BPMS support the conditional event?

The good news for Bizagi customers is that it does now. The above scheme would work in Bizagi BPM Suite - checked.

There must be something wrong deep in the core. It can’t be just prospects’ ignorance, non-perfect software products or greedy consultants. Nobody would say that BPM methodology is inadequate or unusable (well, except ACM proponents but their voices aren’t loud nowadays).

I blogged on the matter already… well, it was 8 years away: 10 Reasons Why BPM Market Doesn’t Meet The Expectations. It wasn’t a final explanation obviously - 10 answers means one doesn’t have the killing answer.

What turned me back to the matter is a thought that I’ve read recently. It was about the real value delivered by a good business consultant. It’s not a specific business receipt or advice; ultimately, it’s about making complex business issues simple.

Now what do we BPM professionals offer in this respect, do we simplify business issues? I’m afraid not.

BPM software isn’t an issue here (IT people love complex toys) but we proudly bring a full-blown discipline, we suggest extensive training programs and introduce new roles to the organization. We create process diagrams. They turned out to be rather complex but we rightfully assure that they are as complex as business is - no more, no less.

This is all true, but… does it make a customer happy? Well, it does - those who are paranoid to do more with less, be more efficient today than yesterday etc. Are they majority of business leaders? I don’t know the big picture but for the selection that I observe the answer is negative.

And what is decision maker’s best alternative? Sweeping garbage under the carpet: keep it as-is, more or less. Imitate a BPM initative by purchasing BPMS software is OK but pulling out business processes from employee’s brains and making them explicit is way too hard, creates too much tension on the way and too much complexity at the end.

Indeed, implicit processes have numerous hidden weak points and hence are less effective, less efficient and way less agile… but who cares, as soon as the majority of organizations around operate this way. See no evil, hear no evil. Not that efficient but simple and manageable from C-level perspective.

Current Digital Transformation trend should break this modus operandi because digital business models implies digital business processes. So hiding processes complexity by delegating them to performers shouldn’t be an option any more.

Now let’s consider events. BPMN events are categorized by type (13 variants) and position (8 variants). Let’s consider event types:

1. None

Neither start nor end events are not strictly necessary - the diagram below is formally correct. Here Task 1 is the implicit start (no input flows), Task 2 is the implicit end (no output flows).

However such diagram looks incomplete and the question arises: was it done intentionally or it’s just a half-work? Therefore the good style supposes the start and end events to be always presented.

As for the intermediate none event, it depicts a process milestone. Not necessary yet useful and intuitive.

2. Link

If it came to the link event then probably it’s time for the decomposition - i.e. to leverage subprocesses. I’d recommend avoiding this event.

3. Timer

Helpful, intuitive, widely used in practice.

4. Conditional

Conditional event is helpful in certain scenarios yet it’s not the most intuitive. One of BPMN benefits is that, if used properly, it’s comprehensible by users without special trainings. It won’t be the case if conditional event is used.

The second issue is that it isn’t supported by most process engines. (In fact I haven’t seen a single one yet.)

But it isn’t that sad: conditional event can be replaced by a timer combined with XOR gateway:

	=
	=

Potential problems of such replacement are excessive engine load and messing the execution log.

5. Message

The major inter-process communication tool (along with data-based communications).

6. Signal

Signal is different from messages in two aspects. First, message is point-to-point while signal is publication-subscribtion. If one needs to connect a sender with a number of receivers then a signal can be replaced by a looped send task:

=

Secondly, message assumes tight while signal - loose coupling. In order to instantiate process B from process A via a message, one needs to have process B model ready:

It’s not the case if signal is used - A and B models may be developed independently. What they they only need to know about each other is the signal name and the payload format, optionally:

When dealing with a complex system of processes, this signal feature becomes much valuable.

There is a workaround for signal in this scenario, too:

Here process A sets a flag in the datastore and process B checks it periodically. If flag isn’t set then B ends, otherwise it resets the flag and proceeds to the core job.

7. Terminate

8. Error

9. Escalation

These three events are more or less interchangeable:

	=
	=

Escalation has a valuable feature - it can create a new token and launch an async control flow in the outer process scope with the help of intermediate escalation initiator and non-interrupting boundary catcher.

10. Multiple

It’s relatively easy to workaround this event.

Catcher:

=

Initiator:

=

=

11. Parallel multiple

It’s quite easy to workaround the parallel multiple event if there are just two events:

=

However in case of many events we’d run into the combinatorial explosion with this technique. Yet in practice I didn’t ever need even two start events. An if I did, I’d use CEP (Complex Event Processing) instead of BPMN.

12. Cancel

13. Compensation

Cancel and compensation events, transactional subprocess and compensation tasks are quite useful in a special scenario “all or nothing”. An example: I’m going to go to the conference. To be prepared, I need: 1) get my submission accepted by the conference committee, 2) book the plane, 3) book the hotel, 4) get my company’s approval on the expenses. It’d be better to perform all the activities in parallel - the less time available, the lower chances to succeed. Every single activity may not succeed and in this case a non-trivial set of compensating activities should be performed, e.g. if the submission was rejected and the plane was booked then the booking should be cancelled etc.

Transactions subprocesses and compensations provide an elegant solution to this kind of tasks. However they are relatively rare so one may not care about transactions and compensations most of the time.

Summary: from total number of 13 event types -

• 4 are essential - none, timer, message, terminate
• 2 are useful - signal, error
• 4 are for special cases - conditional, escalation, cancel, compensation
• 3 are practically useless - link, multiple, parallel multiple

Now let’s consider event categories by position, using message as example:

1. Start

2. End

3. Intermediate initiator

4. Intermediate catcher

These four are essential.

5. Attached event interrupting

Helpful, intuitive, popular.

6. Attached event non-interrupting

Not very intuitive. Can be workarounded, more or less:

=

7. Event subprocess interrupting

8. Event subprocess non-interrupting

Event subprocesses are very similar to attached events. The major difference is that unlike event subprocess, one can’t attach an event to the top-level process. However it’s always possible to make a subprocess from the top-level flow:

Conclusions

Summing up, 5 event positions from 8 are essential: start, end, intermediate initiator and catcher, attached interrupting (this is actually BPMN 1.x subset).

If only essential plus useful types (6 totally) and essential positions (5 totally) are taken then there would be 30 combinations potentially possible from which only 19 are valid:

For the sake of comparison, the total number of valid event combinations in BPMN 2.0 is 63.

• In our day-to-day life we call “process” almost anything from digestion to the formation of galaxies.
• Many consultants are comfortable with the process definitions that cover any orderly set of activites aimed at certain result. It makes sense when we focus on business performance but when we get into details it becomes hard to ignore the difference e.g. between processes and projects. One may treat a project as special case of a process indeed but the fact is that we manage projects and processes substantially differently so a definition that makes no difference between processes and projects would be counter-productive. That’s why I like the term “business capability” - it provides an umbrella term for different kinds of business activities yet it doesn’t merge them all into “process” treated too widely.
• Process definition narrows even more in BPMN context. First, there is a clear difference between a process and subprocess in BPMN: the former is triggered by external event (e.g. a message, timer or free will of process initiator) while the latter is called from overarching process or subprocess. Secondly, the entities more abstract than a single process are beyond BPMN scope completely. There is no element to model process groups in BPMN so one can’t depict things like “value chain”, “supporing processes” or “product promotion”.

Thus, if we look at the process hierarchy through the prism of BPMN, we’d find several levels of process groups at the top, several levels of subprocesses at the bottom and a thin layer of what BPMN calls a process in the middle:

See also:

• What Is a BPMN Process (And What Is Not)

Firstly, exotic elements would make the diagram less comprehensible for business users, leading to refusal in some cases. Probably the biggest BPMN advantage is that it’s both intuitive and strict enough, allowing business users, analysts and IT developers to be on the same page. But this is going to happen only if a good style and healthy minimalism are followed.

Secondly, if BPMS powered processes are considered, no engine implements BPMN completely and strictly. Hence the popular questions: how critical is a given BPMN element being not supported? Is there a workaround?

In this article we’ll investigate BPMN gateways - which ones are must-have and how others can be workarounded. The other BPMN elements will follow.

1. Exclusive gateway (data based)

We won’t try to substitute this one of course.

Side note: empty diamond and the one with a slanted cross inside are just two alternative graphical representations of the same element. It’s pretty obvious that it’s better to follow either one or another style throughout the diagram (or the organization, on that matter).

2. Parallel gateway

The parallel gateway is essential too.

3. Inclusive gateway

Can be replaced by a combination of exclusive and parallel:

=

Inclusive gateway is useful because it models a specific and common enough business scenario: a set of independent options; the alternative diagram presented on the right is more cumbersome. On the other hand, the novice users would hardly get the diagram on the left without explanations.

The process engine may encounter difficulties synchronizing flows at the merge gateway; from this point of view the diagram on the right may have preference, too.

4. Complex gateway

Complex gateway controls tokens on merge. Can be replaced by a pair of exclusive gateways:

=

5. Event-based gateway (exclusive)

Can be replaced with the help of a subprocess:

=

This technique borrowed from Bruce Silver can be used for any combination of events.

If one of the events is message catch then a simpler hint may be used:

6. Start (instantiating) exclusive event-based gateway

=

Both styles should be avoided because 1) they aren’t obvious for business users and 2) most BPMS can’t execute them anyway. Better model flows from each event as a separate process and leverage reusable/call subprocesses.

7. Start (instantiating) parallel event-based gateway

=

This gateway mostly has purely academic value.

Conclusions

It’s basically enough to have just exclusive and parallel gateways. Others may help building more compact diagrams yet their value is diminished by the fact that an average reader not trained in BPMN would hardly understand them.