In BPMN 2.0, how do choreography and conversation diagrams differ from a collaboration diagram of the same hiring interaction?

## Three views of one interaction BPMN 2.0.2 describes three kinds of sub-model in an end-to-end model: **processes** (orchestration), **choreographies**, and **collaborations**, which can include processes and/or choreographies and a **view of conversations**. For a hiring interaction between an employer, a candidate and a background-check agency, each answers a different question. | View | Main elements | Question it answers | |---|---|---| | **Collaboration** | pools, optional processes inside, message flows | who sends which message to whom, and which internal step handles it | | **Choreography** | choreography tasks with participant bands, events, gateways, sequence flow | in what order the parties exchange messages | | **Conversation** | pools, hexagon conversation nodes, conversation links | which subjects the parties communicate about | ## Collaboration: pools and message flows A collaboration usually contains **two or more pools**, one per participant, with **message flows** between them. Each pool may show its private or public process, or be a black box. In the hiring model this is the employer's process with its lanes, and the candidate and agency as pools exchanging the application, the check request and report, and the offer. ## Choreography: the contract between parties The standard describes a self-contained choreography as a **definition of expected behaviour, basically a procedural contract**, between interacting participants. Key features: - It exists **between** pools rather than inside one. - Its activities are **interactions**: each represents a set of one or more message exchanges involving participants, rather than work done by one party. - A **choreography task** is drawn with **participant bands** naming the participants, plus a band with the task name; the band of a participant that is not the initiator has a light fill. - There is **no central controller**, responsible entity or observer of the process. - **Pools and lanes are not used** in choreography diagrams; lanes are sub-partitions of a pool, and a choreography sits between pools when it is shown inside a collaboration. For hiring, a choreography would read: `Employer to Candidate: Invite to interview`, then `Employer to Agency: Request check`, then `Agency to Employer: Report`, then `Employer to Candidate: Offer`. It states the agreed order of exchanges without saying how either side works internally. ## Conversation: a bird's-eye view The conversation diagram is a **particular usage of, and an informal description of, a collaboration diagram**. It adds two graphical elements: 1. **Conversation nodes**: a **conversation** is a hexagon drawn with a single thin line; sub-conversations and call conversations are variants. 2. **Conversation links**, drawn with **double thin lines**, connecting each conversation to the participants involved. A conversation is the **logical grouping of message flows** that relate to a business object and can share a **correlation key**, such as a candidate or application identifier, so each message reaches the right process instance. For hiring there might be three hexagons: `Application` (employer and candidate), `Background check` (employer, agency and candidate) and `Offer` (employer and candidate). The pools of a conversation diagram usually contain no process. ## Choosing the view - To show **how the employer runs hiring** and where it waits for others, use a **collaboration** with the employer as a white box. - To agree an **interaction contract** with the agency without exposing either side's internals, use a **choreography**. - To map **which relationships and topics exist** across many parties before detailing any of them, use a **conversation** diagram. ## Keeping the views consistent The three views describe one interaction, so they must agree. Every exchange in the choreography should correspond to a message flow in the collaboration, and every message flow should belong to one of the conversations. When the hiring process adds a step, such as asking the candidate for consent before the background check, the change touches all three: a new message flow, a new choreography task between employer and candidate, and a message grouped under the `Background check` conversation. A review that checks only the collaboration will miss drift in the other two. ## Common mistakes - Drawing lanes inside a choreography. The standard does not use swimlanes there. - Treating a choreography task as work done by one party. It is an exchange between participants. - Treating a conversation hexagon as a process step. It groups messages and carries no execution order.