A visa application touches three departments, requires documents from the applicant, and has a sub-process that gets reused across five different visa types. Time to learn how processes nest inside processes.
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 Islandis 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 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 objectrepresents 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.
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.
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.
A sub-processlets 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.
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:
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:
Two rules to remember:
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.
Here's how all these elements come together in the visa process:
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.
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 →