Mit BPMN 2.0 werden zwei grundlegend neue Diagrammtypen eingeführt:

• Conversation-Diagramm und
• Choreography-Diagramm.

Choreographiemodellierung dient der Erfassung von Kommunikation über Unternehmensgrenzen hinweg. Dabei werden insbesondere Vereinbarungen der Prozessbeteiligten bezüglich Dokumenten und Nachrichtentypen sowie Reihenfolge des Nachrichtenaustauschs getroffen. Was aus einer Choreographiemodellierung nicht hervorgehen soll, ist die interne Sicht des Prozesses der jeweiligen Prozessbeteiligten, vielmehr sollen globale Interaktionen im Mittelpunkt stehen.

Conversation-Diagramm

Das Conversation-Diagramm wird zur Modellierung von "wer mit wem und was"-Angelegenheiten verwendet. Auf diese Weise können alle Prozessbeteiligten kompakt in einem Diagramm erfasst und spezifiziert werden, welche Kommunikation involviert ist.

Prozessbeteiligte werden in Conversation-Diagrammen als Pools (collapsed, siehe Pools & Lanes) dargestellt. Das Communication-Shape definiert eine Menge von auszutauschenden, inhaltlich zusammenhängenden Nachrichten, die über Conversation-Links mit Pools verbunden werden. Sofern ein multi-instance Pool involviert ist, wird für diesen ein Forked Conversation-Link verwendet.

Darüber hinaus besteht die Möglichkeit, Sub-Conversations zu verwenden, um Abstraktionsebenen zu schaffen.

Choreography-Diagramm

Choreography-Modelle sind wesentlich feingranularer als Conversation-Diagramme. Modelliert wird jeweils eine Choreographie, wohingegen im Conversation-Diagramm in der Regel mehrere Choreographien implizit angedeutet sind. Ebenfalls entscheidend für Choreography-Diagramme ist die Ablaufreihenfolge von Interaktionen zwischen den Prozessbeteiligten, somit können Kommunikationskontrakte zwischen den einzelnen Parteien vereinbart werden.

Ein Choreography-Task repräsentiert eine Interaktion zwischen zwei Prozessbeteiligten. Dabei wird unterschieden zwischen der initiierenden (aktiven) und der empfangenden Partei. Die kommunikationsinitiierende Partei ist ober- oder unterhalb des Choreograhpy-Tasks in weiß dargestellt, wohingegen die empfangende Partei auf der jeweils gegenüberliegenden Seite der initiierenden Partei in grau dargestellt wird. Optional können außerdem die initiierende Nachricht sowie die Antwortnachricht modelliert werden (weiß bzw. graues Briefsymbol).

Darüber hinaus gibt es noch Choreography-Subprozesse, welche selbst wieder eine Choreographie enthalten. Entscheidend ist hier bezüglich der Notation, dass es mehr als eine empfangende Partei geben kann (jedoch nach wie vor eine initiierende). Der Choreography-Subprozess besteht im Einzelnen vor allem aus Choreography-Tasks, die wiederum wie beschrieben jeweils zwei Parteien involvieren; der Subprozess deutet in seiner Notation alle Beteiligten in den einzelnen Choreography-Tasks an.

Choreography-Diagramme bestehen neben Choreography-Tasks und -Subprozessen aus nahezu jedem möglichen BPMN-Element (v.a. Gateways und Events).

Beispiel:
Der folgende Prozess beschreibt die Interaktion zwischen Verkäufer, Bieter/Käufer und Auktionshaus in einem vereinfachten Auktionsprozess. Der Prozess wird gestartet sobald der Verkäufer sein zu verkaufendes Produkt beim Auktionshaus inseriert. Hierfür fertig er eine Produktbeschreibung an und erhält daraufhin vom Auktionshaus eine Auktionsnummer zugeteilt. Wird das Produkt von einem potentiellen Käufer gefunden, kann dieser beim Auktionshaus ein Gebot abgeben. Dieser Task ist als Loop-Aktivität dargestellt, da es in der Regel mehr als einen Bietenden und daher auch mehr als ein Gebot gibt. Wird das Produkt in der vorgegebenen Frist verkauft, initiiert das Auktionshaus die Kaufabwicklung zwischen Verkäufer und Käufer (Höchstbietender), hier als Subprozess angedeutet. Ist das Produkt dagegen nicht verkauft worden, muss der Verkäufer über diesen Umstand informiert werden.