Building spacecraft requires precision timing. Some steps must finish within a deadline. Others only happen if a condition is met. When a task fails mid-execution, the process needs to react immediately.
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.
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.
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.
Before we return to SpaceZ, here's a simple example that shows both event types working together - a bakery process:
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.
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.
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 taskfires. 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.
Back to SpaceZ. Here's how the serial production of new heat panels unfolds when everything goes right - the success path:
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.
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 anevent-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:
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.
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.
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.
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:
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.
Interactive diagram coming soon
This will be a live Crismo canvas you can explore and edit
Model this process yourself
Open a free diagram in Crismo and build what you just learned. No signup needed.
Open in Crismo →