BPMN Diagrams – How To Use End Events (Part 1)

End events describe how a process ends. Often, the end of one process can initiate other behaviors within a business process. Like death and taxes, every business process has an end. Sometimes more than one.

Background

We presented an introduction to BPMN diagrams two weeks ago. Business analysts are often required to document as-is processes and to-be processes. These diagrams help identify the scope of a software project. The diagrams can also help uncover requirements that might be overlooked without diagramming the processes.

The BPMN specification is designed to establish a common language and convention for creating process diagrams. This common convention allows people who are familiar with modeling, but new to a project to avoid learning a new diagramming language on each project or for each client. We have a link to the official version of the spec in our introductory post (we will update that link if and when the spec changes).

End Events

In business process modeling, every process has an ending. In BPMN, every path in every process must lead to an end event. Every process starts with a start event, moves through activities and gateways, and then reaches an end. When processes loop, they can exercise multiple endings.

We could create every desired BPMN diagram using only the normal “none” end event, which simply represents an end to the flow of the process. There are eight different end events, and using them allows us to simplify our diagrams while making them more explicit in describing business processes.

In this part of the article, we will cover the following:

• None (undefined) end events
• Message end events
• Error end events
• Cancel end events

None End Event

This is the end event we will see (and use) most of the time. When a business process model reached an end event, it is complete. When a subprocess reaches an end event, the process flow returns to the parent process.

The none end event specifies that there is no other special behavior associated with the end of the process. In this example, we are born, we pay taxes, and we die. Nothing else happens within this process.

Message End Event

With this message end event example, in addition to terminating the flow of the process, a message is sent by the end event.

This process begins upon receipt of an application (via the message start event), and the application is processed, then the applicant is accepted, and the application fees are deposited. The applicant is notified (after depositing the fees) by the message end event.

We could have added a task called “Notify Applicant” and have that task send a message, and then have the flow move to a none end event. Using a message end event, we eliminate a task as well as an entity to represent the message flow from that task. The message end event provides us with a simpler way to express that the process ends with the sending of a message.

Error End Event

This error end event example shows a simple process for a consumer, who makes a purchase with a credit card. If the credit card is invalid, the business process flow moves to an error end event. The default behavior represents use of a valid credit card, and takes the flow to a task called “Charge Credit Card” and on to a none end event.

The error end event “throws” an error, which can be captured in another part of the process. We explain more about how errors are thrown and caught in our article on intermediate error events.
Cancel End Event

The following business process modeling example shows a purchasing transaction from the perspective of an online retailer.

The online retailer’s process begins with a message start event, moves to the task of “Confirm Product Availability”, and then to the “Fulfill Order” subprocess, and on to the “Record Transaction” task. We’ll come back to the “Notify Customer” step (attached via the error intermediate event).

The “Fulfill Order” subprocess is a transaction (the entire thing happens as one atomic action). The easiest way to think about it is that the entire sub-process happens, or none of it happens. This is indicated by the dual-line border of the expanded sub-process.

Within the “Fulfill Order” subprocess, the retailer first processes the transaction on the credit card. The process spits into two parallel paths at this point – shipping of the product on one path, and confirming the validity of the credit card on the other. Most of the time, the card is valid, and the subprocess flow ends (with the none end event). Running the tasks in parallel allows the retailer to be more responsive to customers, and reduce inventory levels by processing orders more quickly.

However, if the credit card is invalid, the retailer wants to be able to “undo” both the step of shipping the product, and the task for processing the credit card. When the cancel end event is reached, the entire subprocess is cancelled. The cancel end event is designed specifically to cancel an entire transaction whenever something inside the flow of the transaction triggers the cancellation.

The cancel end event (bold circle with an ‘X’ in the center) is processed only when the credit card is invalid. If the credit card is invalid, the retailer wants to “undo” both the shipping of the product and the processing of the credit card. Further, if a card is invalid, the retailer wants to notify the customer.

The cancel intermediate event (defined on the double-line boundary of the expanded sub-process) will “catch” the error that is “thrown” by the sub-process. The task “Notify Customer” is then processed.

Summary

There are still four more bpmn end events that we have not covered. Stay tuned for part two of this article…