Events

An event represents something that happens during a business process — a message arrives, time passes, an error occurs. Unlike activities, events do not perform work of their own: catching events wait for their trigger to occur, while throwing events produce a result and continue immediately.

Two things define an event: its position in the process (start, intermediate, boundary, or end) and its type (what triggers it or what it produces). The same types reappear at every position, so each type is documented on a single page covering all its positions — this page describes the behavior the positions share, and how events handle variables.

Green icons are supported and link to their documentation.

Type	Start	Intermediate		Boundary		End
	Normal	Catch	Throw	Interrupting	Non-Interrupting	Normal
None
Message
Timer
Escalation
Conditional
Link
Error
Signal
Compensation

Not yet supported

None Intermediate Throw Event, Escalation, Conditional, Signal, Compensation, Cancel

Start events

A start event defines the beginning of a process instance. It has no incoming sequence flows and exactly one outgoing sequence flow, and is rendered as a thin single-line circle. When its trigger occurs, a new process instance is created and a token starts moving along the outgoing flow. A process can have multiple start events, each with a different trigger.

The trigger depends on the type:

• None start event — no event definition is attached. The process is started explicitly by a caller, typically through the REST or gRPC API.
• Message start event — a new instance is created each time a matching message is published.
• Timer start event — instances are created on a schedule, without any external trigger.

Start events also appear inside an Event sub process, where message, timer, and error triggers are supported and the start event may be non-interrupting.

Intermediate events

Intermediate events occur between the start and end of a process and are rendered as a double-line circle. They come in two directions:

• Catch events pause the flow: the token waits at the event until the trigger occurs — a message arrives or a timer fires. Message and timer catch events can also follow an Event-based gateway, letting the process react to whichever trigger occurs first.
• Throw events execute as soon as the token reaches them and continue onward — sending a message or jumping to a link target.

Boundary events

A boundary event is attached to the border of an activity via attachedToRef and models what should happen if its trigger occurs while that activity is active. It has no incoming flow and one outgoing flow that defines the alternative path. The engine subscribes to the trigger when the activity starts waiting and removes the subscription when the activity completes — a boundary event never fires for an already-completed activity.

Boundary events come in two flavors, distinguished by the cancelActivity attribute and the border style:

• Interrupting (solid border, the default) — the attached activity is cancelled, together with its jobs, child instances, and other boundary subscriptions, and the token moves along the boundary event's outgoing flow.
• Non-interrupting (dashed border, cancelActivity="false") — the activity keeps running and a new parallel token is created on the outgoing flow.

Boundary events can be attached to Service tasks, Send tasks, User tasks, Business rule tasks, Receive tasks, Sub processes, and Call activities. Supported triggers are message, timer, and error (error is always interrupting).

End events

An end event marks the completion of a process path. It has no outgoing sequence flows and is rendered as a thick single-line circle. A process may have multiple end events; the process instance completes once all of its active tokens have reached one.

What happens when the token arrives depends on the type:

• None end event — the path simply ends without producing any result.
• Message end event — a message is sent before the path ends.
• Error end event — the path ends by throwing a BPMN error that an error boundary event on an enclosing scope can catch.
• Terminate end event (thick circle with a filled dot) — the entire process instance is cancelled immediately: all remaining tokens, active jobs, subscriptions, and called child instances are terminated, regardless of other active paths.

Variables

Events handle variables differently from activities — the direction of the event decides which mappings apply:

Event kind	Mappings	Behavior
Catching events that receive a payload — message start, message catch, message boundary, error boundary	zenbpm:output	Without output mappings, the entire payload is propagated to the catching scope as-is. Add output mappings to propagate only selected variables — except on message start events, where the full payload always becomes the new instance's variables. Note that this is the opposite default from activities, which propagate nothing unmapped.
Throwing message events — message intermediate throw, message end	zenbpm:input / zenbpm:output	Executed as a job, exactly like a Send task: input mappings prepare the variables the worker sees, output mappings propagate the worker's result following the activity rules.
Timer and link events	—	Carry no payload; the process variables are unchanged.

See Variables for the full propagation rules.

Related documentation

• Variables — output-mapping propagation rules for catching events and activities.
• Message events, Timer events, Error events, Link events — the individual event types.
• Event-based gateway — branching on the first of several catch events to trigger.

XML example

The events with no configuration beyond their definition: a none start event, a none end event, and a terminate end event cancelling the whole instance on an alternative path:

<bpmn:startEvent id="Start_Order" name="Order placed">
  <bpmn:outgoing>Flow_Process</bpmn:outgoing>
</bpmn:startEvent>

<bpmn:endEvent id="End_Fulfilled" name="Order fulfilled">
  <bpmn:incoming>Flow_Done</bpmn:incoming>
</bpmn:endEvent>

<bpmn:endEvent id="End_Cancelled" name="Order cancelled">
  <bpmn:incoming>Flow_Cancel</bpmn:incoming>
  <bpmn:terminateEventDefinition />
</bpmn:endEvent>