A BPMN 2.0 hiring model is one pool with lanes Candidate, Recruiting, Hiring manager and Agency, linked by sequence flows; what does it misstate, and how would you restructure it?
answer
- one pool means one controller
- who waits for whom
- private process versus collaboration
- responses that may never come
basics
~20 sIn BPMN 2.0 one pool is one process with one controller, so this model claims the employer sequences the candidate's and agency's actions. Restructure as a collaboration: employer pool with internal lanes, separate participant pools, message flows.
solid answer
~50 sA single pool holds **one private process**, and every sequence flow in it passes that process's token. So the model says the employer's process **drives** the candidate's `Submit documents` and the agency's `Run check`, as if they were internal hand-offs that always happen and happen on the employer's schedule. Three things go wrong: **accountability** (outside parties appear as parts of the employer), **control** (the employer cannot start or finish their work), and **waiting** (there is no place to model a reply that is late or never comes). The fix is a **collaboration**: the employer pool keeps `Recruiting` and `Hiring manager` as lanes; the candidate and the agency become separate participants, usually black-box pools; each cross-party hand-off becomes a message flow, with the employer sending, then waiting at a receiving step. The employer's private process then shows exactly what the employer controls.
go deeper
Recall that a single pool is one process run by one participant, so outside parties do not belong in its lanes.
Explain the difference between a private process and a collaboration, and which hiring parties are participants.
Diagnose what a single-pool model misstates about control, waiting and accountability, then restructure it into pools and messages.
Decide the modelling boundary for cross-organisation processes and how much partner detail a shared diagram should carry.
## The model under review The hiring team drew a single pool titled `Hiring` with four lanes: - **Candidate**: `Submit application`, `Attend interview`, `Accept offer` - **Recruiting**: `Screen application`, `Schedule interview`, `Request background check` - **Hiring manager**: `Interview`, `Decide` - **Agency**: `Run background check` Solid sequence flows connect everything in one chain, from `Submit application` to `Accept offer`. ## What a strict reading says In BPMN 2.0.2 a pool with a process is a **participant** whose process is **fully contained** in the pool. Everything connected by sequence flow belongs to that one process and is ordered by its token. So the diagram asserts: 1. **One controller.** The organisation that owns the process starts and sequences every activity, including the candidate's and the agency's. 2. **Guaranteed hand-offs.** When `Request background check` completes, the token moves directly to `Run background check`; the model has no place for the agency to decline, delay or never answer. 3. **Internal accountability.** The candidate and agency appear as partitions of the employer, the same kind of thing as the Recruiting team. ## Why each assertion is false | Assertion | Reality in hiring | Consequence of the wrong model | |---|---|---| | The employer sequences the candidate | the candidate decides when and whether to respond | no timeout or withdrawal path is modelled | | The agency's check is an internal step | the agency runs its own procedure | turnaround and failure are invisible | | Outside parties are internal teams | they are separate organisations or individuals | responsibility for their steps is misassigned | If the model is ever made executable, the problem becomes concrete: the process would expect to assign the candidate's and agency's tasks as its own work. ## Restructuring into a collaboration BPMN distinguishes a **private process** (internal to one organisation) from a **collaboration** (interactions between two or more participants). The fix moves the model from the first to the second: 1. **Employer pool, white box.** Its private process keeps the lanes `Recruiting` and `Hiring manager`. 2. **Candidate pool, black box** in most cases. The candidate is an independent participant; the employer does not model their private steps. A multi-instance marker can show that many candidates take part. 3. **Agency pool, black box**, unless its procedure is jointly specified. 4. **Messages instead of hand-offs.** The application, interview invitation, check request, check report, offer and acceptance become message flows between pools. 5. **Explicit waiting.** Wherever the employer depends on another party, its own process shows a send step followed by a receiving step, so the model can later add what happens when no reply arrives. ## What changes for the reader - The employer's pool now shows exactly what the employer **controls**. - Each cross-party dependency is visible as a message pair. - Accountability matches the organisation: lanes are internal teams, pools are parties. ## Reviewing the restructured model After the change, walk the employer's pool once more: - Every message the employer sends is followed, somewhere on its own path, by a step that receives the answer or by an explicit decision not to wait. - No sequence flow crosses from the employer pool into the candidate or agency pools. - Each lane names a team the employer actually manages, and no lane names an outside party. - The candidate pool carries a multi-instance marker if the diagram must show that many candidates interact with one hiring process. ## How to tell the difference in an interview The quick diagnostic is to ask, for each lane, **"does our process decide when this work starts?"** If not, the lane is a participant in disguise. For the hiring manager and recruiting team the answer is yes, so they stay lanes. For the candidate and the agency it is no, so they become pools. A senior answer also names what the restructuring does **not** fix: the employer's process must still be designed to handle late or missing replies. Pools make those dependencies visible; handling them is a separate modelling decision about events and flows inside the employer's process.
- In BPMN 2.0, how do you test whether a lane is really a participant in disguise?Ask whether the pool's process decides when that lane's work starts and finishes. Internal teams pass work by sequence flow under one process. If the party acts on its own schedule and only exchanges requests and results, it is a participant and needs its own pool.
- In BPMN 2.0, can the restructured employer pool still be drawn without a boundary?Yes. One pool in a diagram, typically the modeller's own internal process, may be drawn without a boundary. The candidate and agency pools must then have boundaries, because only one pool may omit it.
- In BPMN 2.0, does making the candidate a pool require modelling the candidate's process?No. A pool need not contain a process; a black-box candidate pool shows only the messages exchanged at its boundary. Model the candidate's steps only if the diagram's purpose, such as a candidate-experience study, needs them.
saying these in an interview costs you the question
- Believing lanes for outside parties are just a layout choice
- Assuming one pool can hold several independent parties' processes
- Thinking sequence flows can model a reply that may never arrive
- Keeping internal teams as separate pools to show departments
- Believing a collaboration requires modelling every partner's process