BPMN Compensation Event Correction

bpmn diagram

One of our readers (thank you!) pointed out that another blogger was critiquing one of our earlier business process modeling notation (BPMN) diagrams. Turns out we made a couple mistakes. Here’s a more detailed look at the compensation end event.

The Web-Publishing Process

One of the great things about writing and publishing on the Tyner Blain blog is the feedback loop. In BPMN, it looks a little like this:

blogging process

Usually, when a critic finds a mistake he will point it out to me directly, or traffic will come from the critic’s site, and we’ll find out via our analytics.

It turns out that we did make a couple mistakes, so thanks Bruce for pointing them out.

First, The Mistakes

In one of our articles on end events, we created an example to demonstrate compensation end events, and we had a couple mistakes in the diagram – not too good for a tutorial. Here’s the offending diagram, with a couple annotations in red showing the problems.

bpmn compensation event mistakes

These two mistakes (circled in red) indicate a mis-application of the compensation end event.

The compensating activity, “Record Possible CC Fraud” is a mis-application of the compensation intermediate event, because that task doesn’t actually undo, or compensate for the task to which it is associated (Process Credit Card).

The second mistake is that there are two gateways (a fork and an exclusive OR) that can be reached before the compensation end event, but no other activities. The compensation events, when triggering compensation, are designed to allow you to “go backwards” in the process, and as such, expect that at least one activity is processed before deciding to compensate. The presumption is that if compensation can be initiated without performing any other tasks, then it could happen immediately from within the task that has a compensation intermediate event on its boundary. The gateways don’t count as activities, because they only analyze existing data.

The Corrections

Here’s a new example diagram, without those two errors.

BPMN compensation event example

The first correction shows that the compensating task, “Record Transaction Recision”, is truly something that is done to compensate for recording the transaction. The second change is that there are two distinct tasks between the activity being compensated and the compensation end event. The first task, “Request Credit Card Charge”, sends and receives messages from the bank. This is the task that could cause a compensation (controlled by the gateway’s analysis of the results of that request). The second task, “Notify Customer of Failure” will also occur, but only if the bank denied the charge to the credit card.


Compensation events require that tasks be processed between the task being compensated and the triggering of that compensation. Compensating tasks must compensate for the task to which they are associated.

For the Truly Pedantic

There is also a semantic concern with the original diagram – the original diagram shows that the product would be delivered, even if the credit card charge failed to go through. This could indeed happen – when a vendor is unable to contact the bank, but unwilling to lose a sale. Think about the old “paper charge” handheld machines – they would create a slip that records the transaction in exchange for goods or services – and only later process that transaction, which could fail. But this is a concern, since it is very uncommon these days (only us old folks remember).

There is also another problem, although it may be more of a problem with the BPMN spec than the original diagram. We’ll talk about that in a future article. [Update – it is definitely a problem with the diagram, and not the spec. – Discussion to appear in 20 Sep article]

11 thoughts on “BPMN Compensation Event Correction

  1. The corrected solution seems unnecessarily complex. Why not avoid compensations altogether and fork from the no at the gateway to the “record transaction recission” task.

  2. Hey Callum, thanks for commenting, and welcome to Tyner Blain!

    I think that is an excellent question. I trumped up this example to demonstrate how a compensation works, not to show that a compensation is the best solution for this process.

    That said, I think using a compensation here maintains a clear connection between the rescinding and the recording of the transaction. In a more complex process, this association would be more beneficial.

    I could be convinced either way, for this particular process example.

  3. Hi Scott,
    very interesting your text.
    I’m doing some tests with ARIS Business Architect and I am having some problems to simulate a BPMN diagram with compensation intermediate event. Have you ever tried ARIS?

  4. I’m new using BPMN 2.0 and it is also first time I’m using a Blog.
    I have a naive question. What is the difference between using the TASK “receiving an E-mail” and the INTEMEDIATE EVENT that also make reference to a received message.

    Thanks a lot

    1. Congrats on getting your article accepted, Pieter, and thanks for the citation! Oh, and I’m Scott (there is no Tyner, that’s the name of my company :) ). I really appreciate you including the link – people who find this article these days are working with the current BPMN standards, and I have not stayed current with them, as my practice has taken me in different directions.

Leave a Reply

Your email address will not be published. Required fields are marked *