One use of Intermediate Events is to represent exception or compensation handling. This will be shown by placing the Intermediate Event on the boundary of a Task or Sub-Process (either collapsed or expanded). The Intermediate Event can be attached to any location of the Activity boundary and the outgoing Sequence Flow can flow in any direction. However, in the interest of clarity of the Diagram, we recommend that the modeler choose a consistent location on the boundary. For example, if the Diagram orientation is horizontal, then the Intermediate Events can be attached to the bottom of the Activity and the Sequence Flow directed down, then to the right. If the Diagram orientation is vertical, then the Intermediate Events can be attached to the left or right side of the Activity and the Sequence Flow directed to the left or right, then down.

There are ten (10) types of Intermediate Boundary Events in BPMN: Message, Timer, Escalation, Error, Cancel, Compensation, Conditional, Signal, Multiple and Parallel Multiple. Each type of Intermediate Boundary Event will have a different icon placed in the center of the Intermediate Boundary Event shape to distinguish one from another

An Intermediate Event that is attached to the boundary of an Activity can only be used to “catch” (i.e. respond to) the Event Trigger. The Activity is executed until the Trigger occurs (e.g. a Message is received). If the Event is interrupting, the Activity will be canceled and the Token will move down the exception path connected to the Intermediate Boundary Event. If the Event is non-interrupting, the Activity will continue and a new Token is generated for the exception path. Both the normal and the exception paths will continue in parallel.

Marker	Description
	A Message arrives from a participant and triggers the Event. If a Message Event is attached to the boundary of an Activity, it will change the Normal Flow into an Exception Flow upon being triggered. For a Message Event that interrupts the Activity to which it is attached, the boundary of the Event is solid. For a Message Event that does not interrupt the Activity to which it is attached, the boundary of the Event is dashed. The actual Participant from which the Message is received can be identified by connecting the Event to a Participant using a Message Flow within the definitional Collaboration of the Process.
	A specific time-date or a specific cycle (e.g., every Monday at 9am) can be set that will trigger the Event. If a Timer Event is attached to the boundary of an Activity, it will change the Normal Flow into an Exception Flow upon being triggered. For a Timer Event that interrupts the Activity to which it is attached, the boundary of the Event is solid. For a Timer Event that does not interrupt the Activity to which it is attached, the boundary of the Event is dashed.
	This type of Event is used for handling a named Escalation. If attached to the boundary of an activity, the Intermediate Event catches an Escalation. In contrast to an Error, an Escalation by default is assumed to not abort the activity to which the boundary event is attached. However, a modeler may decide to override this setting by using the notation described in the following. For an Escalation Event that interrupts the Activity to which it is attached, the boundary of the Event is solid For an Escalation Event that does not interrupt the Activity to which it is attached, the boundary of the Event is dashed.
	An Intermediate Error Catch Event can only be attached to the boundary of an activity, i.e., it may not be used in Normal Flow. If used in this context, it reacts to (catches) a named error, or to any error if a name is not specified. Note that an Error Event always interrupts the Activity to which it is attached, i.e., there is not a non-interrupting version of this Event. The boundary of the Event is thus always solid.
	This type of Intermediate Event is used within a Transaction Sub-Process. This type of Event MUST be attached to the boundary of a Sub- Process. It SHALL be triggered if a Cancel End Event is reached within the Transaction Sub-Process. It also SHALL be triggered if a Transaction Protocol “Cancel” message has been received while the Transaction is being performed. Note that a Cancel Event always interrupts the Activity to which it is attached, i.e., there is not a non-interrupting version of this Event. The boundary of the Event is thus always solid.
	When attached to the boundary of an Activity, this Event is used to “catch” the Compensation Event, thus the Event marker MUST be unfilled. The Event will be triggered by a thrown compensation targeting that Activity. When the Event is triggered, the Compensation Activity that is Associated to the Event will be performed. Note that the interrupting and non-interrupting aspect of other Events does not apply in the case of a Compensation Event. Compensations can only be triggered after completion of the activity to which they are attached. Thus they cannot interrupt the Activity. The boundary of the Event is always solid.
	This type of event is triggered when a Condition becomes true. A Condition is a type of Expression. If a Conditional Event is attached to the boundary of an Activity, it will change the normal flow into an exception flow upon being triggered. For a Conditional Event that interrupts the Activity to which it is attached, the boundary of the Event is solid. For a Conditional Event that does not interrupt the Activity to which it is attached, the boundary of the Event is dashed.
	The Signal Event can only receive a Signal when attached to the boundary of an activity. In this context, it will change the Normal Flow into an Exception Flow upon being triggered. The Signal Event differs from an Error Event in that the Signal defines a more general, non-error condition for interrupting activities (such as the successful completion of another activity) as well as having a larger scope than Error Events. When used to “catch” the signal, the Event marker will be unfilled. For a Signal Event that interrupts the Activity to which it is attached, the boundary of the Event is solid. For a Signal Event that does not interrupt the Activity to which it is attached, the boundary of the Event is dashed.
	A Multiple Event indicates that there are multiple Triggers assigned to the Event. When attached to the boundary of an activity, the Event can only “catch” the Trigger. In this case, only one of the assigned Triggers is required and the Event marker will be unfilled upon being triggered, the Event that occurred will change the Normal Flow into an Exception Flow. For a Multiple Event that interrupts the Activity to which it is attached, the boundary of the Event is solid. For a Multiple Event that does not interrupt the Activity to which it is attached, the boundary of the Event is dashed.
	This means that there are multiple triggers assigned to the Event. When attached to the boundary of an activity, the Event can only “catch” the trigger. Unlike the normal Multiple Intermediate Event, all of the assigned triggers are required for the Event to be triggered. The Event marker will be an unfilled plus sign. For a Parallel Multiple Event that interrupts the Activity to which it is attached, the boundary of the Event is solid. For a Parallel Multiple Event that does not interrupt the Activity to which it is attached, the boundary of the Event is dashed.