Bpmn Event Definitions and Trigger Types Explained

If you've ever stared at a BPMN diagram and wondered why some circles have solid borders while others are dashed, or what that little envelope icon inside an event actually means, you're not alone. Event definitions and trigger types are where most people start getting confused with BPMN. But understanding them is the difference between a process diagram that accurately describes business behavior and one that leaves your team guessing. This article breaks down every event definition and trigger type in plain language, so you can model processes that actually work.

What Are BPMN Events and Why Do They Have Different Definitions?

In BPMN, an event is something that happens during a process. It might be the reason a process starts, something that interrupts work mid-flow, or the final outcome that closes a process. Events are drawn as circles, and what goes inside that circle is the event definition, also called the trigger type.

The event definition tells you what kind of thing is happening. Is it a timer going off? A message arriving? An error occurring? Without the trigger type, a circle in a diagram is just a circle. With it, the event communicates precise behavior to developers, analysts, and stakeholders who need to execute or audit that process.

You can find a quick visual overview of how events fit among other symbols in a BPMN diagram elements cheat sheet, but here we'll go deeper into each definition type.

What Are the Three Positions Where Events Can Appear?

Before getting into trigger types, it helps to know where events sit in a process flow. The position changes the meaning:

Start events These kick off a process or a subprocess. They have a single thin border circle.
Intermediate events These sit between start and end, attached to a sequence flow or to the boundary of an activity. They have a double border circle.
End events These terminate a process path. They have a thick (bold) border circle.

Not every trigger type works at every position. For instance, a cancel event can only appear as an intermediate or end event. Knowing the positional constraints is just as important as knowing the symbols themselves.

What Does Each Event Definition Actually Mean?

None Event (Plain Circle)

A none event has no icon inside the circle. A none start event means the process begins without a specific external trigger the process is started manually or by default. A none end event simply means the process path ends. This is the most common type you'll see, especially in simple workflows.

Message Event (Envelope Icon)

Message events represent communication between participants, pools, or external systems. A message start event means the process starts when a message arrives, like receiving a customer order via API. A message intermediate event on the flow means the process waits for a message before continuing. An intermediate message event attached to an activity boundary means a message could arrive while the activity is running, potentially interrupting it.

Message end events send a message when the process path completes. This is useful when one process needs to notify another upon finishing its work.

Timer Event (Clock Icon)

Timer events introduce time-based behavior. A timer start event triggers a process on a schedule every Monday at 9 AM, for example, or on the first day of each month. A timer intermediate event on the flow acts as a delay, pausing the process for a specified duration. A timer boundary event attached to an activity sets a deadline: if the task isn't done within the time limit, the engine can escalate or redirect.

Timer events are heavily used in SLA monitoring and approval workflows. If a manager hasn't approved a request within 48 hours, a timer boundary event can trigger an escalation path. For more on how timers interact with gateways and conditional routing, check the gateway comparison chart.

Error Event (Lightning Bolt Icon)

Error events handle exceptions and faults. You won't find error start events at the top level of a process, but they can start an event subprocess. Error intermediate events are almost always attached to the boundary of a subprocess or activity, meaning: "If this task throws a defined error, catch it here and redirect the flow." An error end event throws an error that a parent process or subprocess can catch.

Practical example: A payment processing activity might have an error boundary event. If the payment gateway returns a failure, instead of crashing the workflow, the error is caught and routed to a manual review task.

Signal Event (Triangle Icon)

Signals work like a broadcast. Unlike messages, which go from one sender to one specific receiver, a signal is thrown and can be caught by any process instance listening for it. This makes signal events useful for cross-process communication.

A signal start event begins a new process instance whenever the signal is thrown elsewhere. A signal intermediate catch event pauses the current flow until the signal arrives. A signal intermediate throw event broadcasts the signal for others to catch. In a manufacturing environment, a quality check failure in one process could throw a signal that pauses production in a separate, parallel process.

Conditional Event (Document with Lines Icon)

A conditional event triggers when a specific business condition becomes true. Unlike a message, nobody sends it the engine evaluates a boolean expression. A conditional start event begins a process when a condition is met, such as when inventory drops below a threshold. A conditional intermediate event waits on the flow until the condition evaluates to true.

These are less common in everyday modeling but powerful in rules-driven automation scenarios.

Compensation Event (Rewind Arrow Icon)

Compensation events handle undo logic. If a completed activity needs to be reversed like canceling a confirmed booking the compensation mechanism defines what "undo" means. A compensation intermediate throw event triggers the compensation handler. A compensation boundary event attached to an activity ensures that compensation logic runs if the activity is compensated.

Compensation is not the same as error handling. Errors catch failures. Compensation undoes things that successfully completed but now need to be reversed due to a later decision or event.

Cancel Event (X Icon)

Cancel events are tied specifically to transaction subprocesses. A cancel end event inside a transaction subprocess triggers the transaction's cancellation mechanism, which rolls back all participants. A cancel intermediate boundary event on a transaction subprocess catches the cancellation and allows the process to handle the failure gracefully.

You won't use cancel events in regular subprocesses or top-level processes. They're limited to transaction contexts by design.

Escalation Event (Upward Arrow Icon)

Escalation events communicate between a subprocess and its parent process. An escalation start event begins an event subprocess when an escalation is thrown. An escalation boundary event catches an escalation thrown by a child subprocess. An escalation end event throws an escalation to the parent.

Think of escalation as a way for a subprocess to say: "I can't handle this at my level pass it up." It's different from an error because the subprocess may continue after throwing the escalation, depending on whether the throw is interrupting or non-interrupting.

Terminate Event (Filled Circle Icon)

A terminate end event immediately ends all active paths in the process instance. It's a hard stop. If your process has parallel branches and one of them reaches a terminate end event, all other branches are killed instantly, regardless of their state.

Use this sparingly. It's appropriate when any further execution is meaningless for instance, when a customer cancels an entire order and there's no value in completing the remaining fulfillment steps.

Link Event (Arrow Icon)

Link events act as a go-to connector within a single process level. A link throw event is a source; a link catch event is a destination. They don't trigger anything external they simply redirect the flow. This is primarily a diagram layout tool to avoid long, crossing sequence lines. Use them to keep complex diagrams readable.

Multiple and Parallel Multiple Events

A multiple event has several trigger definitions, but only one needs to occur to activate the event. A parallel multiple event requires all defined triggers to occur before it activates. These are less frequently used because they add modeling complexity, but they apply when a process genuinely depends on multiple different types of stimuli.

What's the Difference Between Interrupting and Non-Interrupting Events?

When a boundary event is interrupting (solid circle border), it cancels the activity it's attached to and redirects the flow. When it's non-interrupting (dashed circle border), the activity continues running while an alternative path is started in parallel.

Example: A timer boundary event on an approval task. If interrupting, the timer replaces the approval task with an escalation. If non-interrupting, the timer sends a reminder while the approval task keeps running. This distinction has real operational impact, so model it carefully. You can see how boundary events interact with activity types in the full BPMN symbol reference guide.

What Are Common Mistakes When Modeling Event Definitions?

Using a plain start event when a trigger exists. If a process starts because a message arrives, model a message start event not a none start event with a note on the side.
Forgetting interrupting vs. non-interrupting. This is the most common modeling error. Always check the border style. Solid means it interrupts; dashed means it doesn't.
Applying cancel events outside transaction subprocesses. Cancel events only work inside transaction contexts. Using them elsewhere is invalid BPMN.
Confusing signals with messages. Messages are point-to-point. Signals are broadcast. If only one specific process should respond, use a message.
Overusing terminate events. Terminate kills everything. If only one path should end, use a normal none end event instead.
Ignoring compensation chains. If you model compensation, make sure the activity being compensated was actually completed. Compensation on a skipped activity does nothing.

How Do Event Definitions Affect Process Engine Execution?

If you're building executable processes in a BPM engine like Camunda, Flowable, or jBPM, event definitions aren't just documentation. They directly control runtime behavior. A message event in the model means the engine will create a subscription and wait for a matching message correlation. A timer event means the engine schedules a job. Getting the event definition wrong means the engine does the wrong thing at runtime, which leads to stuck process instances, missed escalations, or unintended terminations.

Always validate your model against the execution semantics of your target engine. Not all engines support every event type equally.

Quick Reference: Which Event Definitions Work at Which Position?

Start events: None, Message, Timer, Signal, Conditional, Multiple, Parallel Multiple
Intermediate catch events: Message, Timer, Signal, Conditional, Multiple, Parallel Multiple, Link (catch)
Intermediate throw events: Message, Signal, Escalation, Compensation, Multiple, Link (throw), None
Boundary events: Message, Timer, Signal, Error, Escalation, Cancel, Compensation, Conditional, Multiple, Parallel Multiple
End events: None, Message, Signal, Error, Escalation, Cancel, Compensation, Terminate, Multiple

Practical Next Steps and Checklist

Before finalizing your next process diagram, run through this checklist:

Every start event has the correct trigger type don't default to "none" out of habit.
Boundary events clearly show interrupting vs. non-interrupting with the correct border style.
Cancel events only appear inside transaction subprocesses.
Compensation events have matching compensation handlers defined on the relevant activities.
Signal vs. message usage matches the actual communication pattern (broadcast vs. point-to-point).
Timer events include defined durations, dates, or cycle expressions not just a vague "waits."
Terminate events are only used when truly all process paths should stop.
Your model passes validation against your BPM engine's supported event types before deployment.

Start by auditing one existing process diagram using this list. You'll likely catch at least two or three event definition issues that affect how the process behaves in production.