The Space Ship: Timer, Conditional & Attached Events in BPMN

Welcome to SpaceZ

SpaceZ is a private spaceship manufacturer. Their spacecraft re-enter
the atmosphere at thousands of degrees - and the only thing standing between the crew
and incineration is a set of heat-resistant panels. The engineering
team has just developed a new generation of these panels. Now it's up to the production
team to manufacture them.

The stakes are high. A faulty panel could endanger lives. The process needs to be fast,
precise, and crystal clear - with built-in safeguards for when things go wrong. Three
teams are involved: the Planning Department, which procures raw
materials and creates the production plan; Quality Assurance, which
checks both the plan and the finished samples; and the Production Team,
which adjusts machinery and manufactures the panels.

To model this process, you need elements you haven't seen before - events that react
to time, events that react to conditions, and events that can
interrupt a task that's already running.

  ## When Time Is the Trigger

SpaceZ's development department hands over new products on a quarterly schedule. The
production process doesn't start when someone presses a button - it starts when
a new quarter begins. That's a timer start event.

In BPMN, timer events are drawn with a small clock symbol inside the circle. They
represent specific dates, deadlines, or durations. Think of an audit triggered at
the start of every quarter, or a warehouse check that takes exactly one week.

Here's a crucial detail: timer events are always catching events.
Why? Because time isn't something you can trigger - it simply happens. You can send
a message (that's a throwing event), but you can't send time. You can only
wait for it. That's why BPMN has no throwing timer events.

  > **Timer events** use a clock symbol. They represent dates, deadlines, or durations.

Timer events are always catching - you can't send time, only wait for it.

  ## Waiting for a Condition

Timer events wait for a point in time. Conditional events wait for
a situation to become true.

Imagine a warehouse where stock is running low. The condition "only one unit left
in stock" is either true or false. A conditional event holds the token in place
until the condition flips to true - then the process continues.

Like timer events, conditional events are always catching. Whether a
condition becomes true or not cannot be directly controlled - it depends on the state
of the world. So in BPMN, conditional events simply happen, just like time does.

  ## A Quick Detour: The Bakery

Before we return to SpaceZ, here's a simple example that shows both event types
working together - a bakery process:

  - The process starts with a **timer start event** - triggered every day.

• The staff prepares the dough.
• A timer intermediate event pauses the process for 25 minutes while the dough rises.
• The dough goes into the oven.
• A conditional intermediate event holds the token until the condition "the bread is brown" becomes true.
• The staff takes the bread out. Process complete - freshly baked bread.

Simple, but it shows the concept: timers wait for a moment, conditionals
wait for a state. Now let's apply these ideas somewhere the stakes are much higher.

  ## Events Attached to Tasks

So far, you've only seen events between tasks - one task ends, the event
fires, the next task begins. But BPMN has a more powerful trick: events can be
** attached directly to a task**.

An attached event sits on the boundary of a task - literally drawn on its edge. While
the task is being worked on, the event listens. If the event triggers while the task
is still running, it interrupts the task and redirects the token to
an alternative path.

Think of a task with a deadline. If the deadline expires while the work is still in
progress, the attached timer event fires, the task is cancelled, and the process
takes a different route - perhaps delegating the work to someone else.

Only catching events can be attached to tasks. This makes sense -
attached events are waiting for something to happen while the task runs.
You can attach timer events, conditional events, message events, and more.

  > **Attached events** sit on the boundary of a task. If triggered while the task

is running, they interrupt it and redirect the token to an alternative path. Only
catching events can be attached.

  ## An Example: The Bookworm Store

Here's a quick illustration. In the Bookworm store, when a book is
out of stock, the sales manager must procure it. But the store has a policy:
customers can cancel their order at any time during procurement.

While the sales manager is working on procurement, the token stays inside the task.
If the customer cancels, a conditional event attached to the task
fires. The procurement stops immediately, and the token takes the alternative path
to handle the cancellation.

The key insight: the sales manager stops the current task and continues
with whatever the alternative flow requires. The attached event doesn't wait for the
task to finish - it interrupts it.

  ## The Heat Panel Process: Success Path

Back to SpaceZ. Here's how the serial production of new heat panels unfolds when
everything goes right - the success path:

  - A **timer start event** triggers the process at the beginning of each
      quarter, aligning with the development department's handover schedule.

• The Planning Department checks if enough raw material is available. If yes, the token passes through an exclusive gateway and moves forward.
• The Planning Department creates the production plan. The token then passes a ** plain intermediate event** - a milestone marker that doesn't influence the flow. It simply says: "we've reached an important point."
• A parallel gateway splits the token: Quality Assurance assesses the plan while the Production Team informs staff about the upcoming work.
• Both tokens merge at a closing parallel gateway. An exclusive gateway checks whether Quality Assurance approved the plan.
• If approved, the Production Team adjusts the machines and produces the first samples. Note the attached conditional event on this task - if visual defects appear during production, the event fires and stops the task immediately.
• Assuming no defects, Quality Assurance inspects the samples. If they pass all material tests, the panels are approved and the process ends successfully.

Ten tasks, three teams, one clean path from start to finish. That's the ideal
scenario. But SpaceZ doesn't live in an ideal world.

  ## When the Material Isn't There

What happens when the raw material check fails? The token takes the downward path.
The Planning Department records the missing components, and the token reaches an
event-based gateway.

The event-based gateway is the fourth and final gateway in BPMN. Unlike the others,
it doesn't make a decision - it waits for external events. The process
pauses until one of several possible events occurs. Like the exclusive gateway, only
one path activates - but the choice is made by which event happens first,
not by a condition.

At SpaceZ, two events are possible:

  - The components arrive - a **catching message event** fires, and the
      process continues with production planning.

• Three days pass with no delivery - a timer event fires, and the Production Team sources the components directly from the supplier.

Only one of these events can occur. Even if the components arrive at the exact same
millisecond the timer expires, BPMN assumes one happens slightly before the other.
No ambiguity.

  ## When the Plan Gets Rejected

Quality Assurance reviews the production plan and finds issues. The token is sent
back to the Planning Department for adjustments. Once updated, the revised plan
returns to Quality Assurance for re-assessment while the Production Team informs
staff about the changes.

This time Quality Assurance is satisfied. The plan is approved, and the Production
Team can begin adjusting the machines.

  ## When the Samples Fail

During production, the attached conditional event detects visual defects in the
samples - a cut in the panel surface. The event fires immediately. Production stops.
The token takes the alternative path back to the machine adjustment step.

The Production Team readjusts the machines and produces a second batch. This time
no visual defects appear, but Quality Assurance still isn't satisfied with the
material test results. The samples are rejected, and the cycle repeats - a third
round of machine adjustment and sampling.

Finally, the third batch passes all inspections. Quality Assurance approves the
samples, and the process terminates successfully.

  ## What You've Learned

With the elements from this chapter, you can now model about 90% of the
processes you'll encounter in the real world. Here's what you've added to
your toolkit:

  - **Timer events** - represent specific dates, deadlines, and durations.
      Always catching, because time simply happens.

• Conditional events - represent conditions that are either true or false. Always catching, because conditions can't be directly controlled.
• Attached (boundary) events - sit on a task's edge and interrupt it when they fire. Only catching events can be attached.
• Event-based gateway - waits for one of several events to occur, then takes that path. Closed with an exclusive gateway, since only one path activates.

The SpaceZ process combined all of these: a timer that starts the quarterly cycle,
conditions that halt production when defects appear, attached events that interrupt
tasks mid-execution, and an event-based gateway that waits for materials or a
deadline. These are the tools for processes where timing, exceptions, and external
triggers matter.

---

This is part of the Learn BPMN series on ProcessCamp - 11 real-world scenarios to master process modeling. Try modeling this yourself in Crismo - free, no signup needed.