The Travel Agency: Sub-Processes, Call Activities & Data in BPMN

You Deserve a Holiday

After mastering events, gateways, and parallel work, you've earned a break. So let's
take a trip to Paradise Island - white sand, turquoise water, zero
exclusive gateways.

There's just one problem. You applied for your visa four weeks ago, and it still
hasn't arrived. Your luggage is packed. Your flight is booked. But the embassy?
Radio silence.

You pick up the phone and call. Turns out the Embassy of Paradise Island is
famously old-fashioned - every process is paper-based, nothing is digitalized. The officer
apologizes and walks you through what's been happening behind the scenes. As you
listen, you sketch the process in BPMN. Suddenly you can see exactly where your
application is stuck - and why it takes so long.

  ## The Documents

The visa process starts the moment you send your documents to the embassy. From a BPMN
perspective, that's a message start event - something arrives from
outside. But this time, we want to make the documents themselves visible in the diagram.

A data object represents any piece of data flowing through a process -
a business document, an email, a form, a letter. It's drawn as a page with a folded
corner, and it connects to tasks with a dashed arrow. The arrow direction tells you
whether the task reads the data (arrow pointing to the task) or writes it
(arrow pointing away from the task).

In the visa process, the first data object is the visa application form you
filled out. The back office reads it to check whether your documents are complete. A second
data object - your supporting documents (passport copies, photos, proof of
accommodation) - flows alongside it.

Data objects are always optional. You don't need to attach one to every
task that touches data. But when you want to highlight which documents matter - for
instance, when designing a document management system - they make the process far
more expressive.

  > **Data objects** (page icon with folded corner) represent documents flowing through

the process. Data stores (cylinder) represent persistent storage. Both are
optional - use them when you want to highlight which data matters.

  ## The Applicant Database

After the back office checks your documents, they create an entry in the embassy's
applicant tracking system. This isn't a document that flows with the process and
disappears - it's a persistent record that outlives your individual application.

That's a data store. Unlike a data object, which exists only during
the process, a data store persists beyond the lifetime of any single process instance.
Think of it as a database, a CRM, a filing cabinet - something that was there before your
application arrived and will be there after it's processed.

The data store is drawn as an open cylinder. When a task writes to it, the arrow points
from the task to the store. When a task reads from it, the arrow goes the other direction.
In the visa process, the back office writes your record to the applicant
database, and later the visa officer reads it when making the final decision.

  ## Three Departments, One Process

Your application doesn't stay in one department. The back office checks
whether documents are complete. The compliance department runs background
checks and verifies document authenticity. The visa officer makes the
final decision.

That's three lanes inside the embassy pool. Each department handles its part, and
the sequence flow crosses lane boundaries to move responsibility from one team to the
next - no extra handover tasks needed.

But here's where it gets interesting. The compliance department's document
verification involves several steps: checking watermarks, validating stamps, cross-referencing
with issuing authorities. It's a process within the process.

  ## Nesting Processes: The Sub-Process

A sub-process lets you take a group of related tasks and collapse them
into a single activity with a small plus sign. Click the plus, and the detail expands.
Close it, and you're back to the high-level view.

When the token reaches a sub-process, it enters the underlying detail and works through
it like any other process - start event, tasks, gateways, end event. Meanwhile, the
token in the parent process waits. Only when the sub-process token reaches
its end event does the parent token get released to continue.

This introduces hierarchy levels in BPMN. The parent process is Level 1 -
a high-level overview. The sub-process is Level 2 - the detailed breakdown. You can
abstract information at Level 1 and provide all the granularity at Level 2.

In the visa process, "Verify documents" is a sub-process. At Level 1, it looks
like a single task. At Level 2, it expands into checking watermarks, validating stamps,
cross-referencing authorities, and recording results. The visa officer doesn't need
to see those details - they just need to know: documents verified, yes or no.

  > **Sub-processes** group related tasks into a collapsible container (marked with a +).

The parent process waits while the sub-process runs. This creates hierarchy: Level 1 is the
overview, Level 2 is the detail.

  ## Reuse: The Call Activity

Now here's the thing. The embassy doesn't just process tourist visas. They
handle business visas, work visas, student
visas, and transit visas. Each visa type has its own process.
But every single one of them needs document verification.

If document verification were a regular sub-process, you'd have five copies of the
same verification steps - one embedded in each visa process. Change one step (say,
add a new security check), and you'd have to update it five times. That's
a maintenance nightmare.

A call activity solves this. It looks like a sub-process - a task with
a plus sign - but with a bold border. That bold border signals: the
underlying process is globally defined. It exists independently and can be
invoked by any process that needs it.

All five visa processes call the same globally defined document verification process.
Update it once, and every visa type benefits. The call activity is BPMN's answer
to reusable components - define once, use everywhere.

The difference is subtle but important:

  - **Sub-process:** The detail belongs to *this* process. It's embedded.
      One parent, one child.

• Call activity: The detail is globally defined. Many parents can call the
  same child. Bold border = shared.

  ## When the Diagram Gets Too Big

The embassy's full visa process - all three departments, all the checks, the
decision tree - is massive. Printed out, it covers an entire wall. Business users
lose track halfway through. That's not useful.

You already know how to use sub-processes to create hierarchy. But sometimes the
process is huge even at one level - too many paths crossing each other, arrows
weaving left and right and looping back.

Link events solve this. They always come in pairs: a throwing
link event and a catching link event. Together, they replace
a sequence flow. The throwing event sends the token, and the catching event receives
it - both carry the same name so you know they belong together.

Link events are useful in two situations:

  - **Avoiding crossing flows:** When a sequence flow would have to cross over
      other flows (reducing readability), replace it with a pair of link events. The throwing
      event sends the token; the catching event receives it on the other side - no crossing
      needed.

• Slicing large processes: Cut an oversized process into two or three
  manageable sections. For every sequence flow you cut, add one pair of link events to
  reconnect. Three cuts = three pairs = six link events. Each section can be read independently.

  ## Rules for Link Events

Two rules to remember:

  - Only **intermediate** link events exist. There are no link start events
      or link end events.

• Link events are for slicing a single process into parts - not for connecting separate follow-up processes. For that, use normal start and end events.

How do you know whether something is a "second part of the same process" or a
"follow-up process"? Ask yourself: What is the goal of this process? In the
shoe shop, the goal was selling shoes. Cleaning them afterward is a different goal - a
follow-up process. But the back office check and the visa officer's decision share
the same goal: processing the visa application. That's one process, potentially
sliced with link events.

  ## The Full Picture

Here's how all these elements come together in the visa process:

  - **Data objects** make the visa application form and supporting documents
      visible as they flow between departments.

• A data store represents the applicant database - persistent, shared, outliving any single application.
• A sub-process hides the detailed verification steps behind a clean "Verify documents" label at Level 1.
• A call activity makes that verification reusable across tourist, business, work, student, and transit visa processes.
• Link events slice the overall process into readable sections so no one has to follow arrows across a wall-sized diagram.

Your visa application? It was stuck in the compliance department - the document verification
sub-process was waiting on a response from the issuing authority. Now that you can read
the process, you know exactly where to follow up. And when you finally land on Paradise
Island, you'll appreciate the process that got you there - even if it took a few
extra weeks.

---

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.