Choreography Tasks, Participants, and Sequence Flows

Imagine you’re finalizing a contract with a vendor, and both parties need to agree on the exact sequence of messages—acknowledgments, confirmations, data submissions—without revealing internal workflows. That’s where BPMN choreography tasks come in.

This moment—when clarity of interaction matters more than internal process details—is where choreography diagrams deliver their highest value. They’re not about what each participant does internally. They’re about what they say to each other, and in what order.

Many beginners start by modeling internal steps too early. They draw tasks, gateways, and lanes—only to realize later that the real issue isn’t internal logic, but misaligned expectations about who sends what, and when.

After two decades of modeling complex integrations across finance, healthcare, and logistics, I’ve seen this pattern repeat. The solution? Step back. Use choreography tasks to define the agreed-upon message flow. This is not a process diagram. It’s a contract in visual form.

By the end of this chapter, you’ll know how to model choreography tasks, identify initiating and non-initiating participants, and use choreography sequence flow to express precise interaction order—without a single internal activity.

What Are BPMN Choreography Tasks?

BPMN choreography tasks represent a message exchange between participants. They are not internal work. They are not actions performed by a single actor. They are events of communication.

Unlike a regular BPMN task, which implies a unit of work (e.g., “Process Payment”), a choreography task is purely communicative. It’s a message sent or received—like “Send Invoice” or “Receive Confirmation.”

Think of it this way: a regular task says, “I will do something.” A choreography task says, “We will exchange this message.”

This shift in focus—from internal work to shared communication—is the core of choreography modeling.

For example, in a B2B order flow, the choreography task “Send Order Confirmation” isn’t owned by one party. It’s a shared event: the buyer sends it, and the seller receives it. The choreography diagram captures that moment, not the internal steps that follow.

Choreography Tasks vs. Regular BPMN Tasks

Let’s compare them directly:

• Regular BPMN Task: Represents a unit of work performed by a participant. It has a name like “Validate Customer Data” and is located within a pool or lane.
• BPMN Choreography Task: Represents a message exchange. It appears in the choreography diagram, not inside any pool. It has a name like “Send Payment Notice” and is connected via choreography sequence flow.

Here’s the key distinction: a choreography task has no internal process. It’s a boundary event in the conversation, not an internal step.

This is why choreography diagrams are often used to define service contracts, API interactions, or integration agreements. They’re not about implementation—they’re about agreement.

Participants in BPMN Choreography

Participants in BPMN choreography are the actors involved in the message exchange. They’re represented as pools in the diagram, just like in collaboration diagrams.

But here’s the difference: in choreography, each pool is a participant in a shared conversation. There’s no internal structure. No lanes. No sequence flows inside the pool.

Each participant is responsible for sending or receiving messages at the appropriate time. The choreography diagram defines the expected behavior of each participant, not their internal process.

Initiating vs. Non-Initiating Participants

One of the most practical distinctions in choreography is whether a participant initiates a message.

An initiating participant is the one who sends the first message in the sequence. For example, in a customer onboarding flow, the customer might initiate by sending a “Registration Request.”

A non-initiating participant waits to receive the first message. In the same flow, the system might be non-initiating, waiting to receive the registration request before responding.

This distinction is critical when modeling contracts or service-level agreements. It defines who starts the interaction—and who is expected to respond.

Use visual cues: initiating participants often have a message flow that starts from their pool. Non-initiating ones receive from others.

Choreography Sequence Flow: The Backbone of Message Order

The choreography sequence flow is the line that connects choreography tasks. It defines the order in which messages are exchanged.

Unlike sequence flows in process diagrams, which represent internal logic, choreography sequence flows represent the agreed-upon order of communication.

They are always directed from one choreography task to another. They never go inside a pool. They never connect to internal activities.

Here’s a simple pattern:

• Participant A sends Message 1
• Participant B receives Message 1
• Participant B sends Message 2
• Participant A receives Message 2

This sequence is represented as a chain of choreography tasks linked by choreography sequence flows. The flow shows that the interaction must happen in this exact order.

When you model choreography sequence flow, you’re not modeling what happens inside. You’re modeling what must happen between parties.

Common Choreography Patterns

Here are three recurring patterns you’ll see in real-world choreography diagrams:

1. Request-Response: One participant sends a request, the other responds. This is the most common pattern in API and service contracts.
2. Two-Way Synchronization: Both participants send and receive messages in alternating order. Useful for real-time data exchange.
3. One-Way Notification: One participant sends a message, and the other receives it without a reply. Common in event-driven systems.

Each pattern uses choreography sequence flow to enforce the correct order. No flow means no agreement.

Practical Modeling Steps: Building a Choreography Diagram

Here’s how I approach choreography modeling in real projects:

1. Identify the participants: Who is involved in the interaction? List them clearly. Use consistent names across diagrams.
2. Define the message exchange sequence: Walk through the conversation step by step. What is sent first? What is expected in response?
3. Model each message as a choreography task: Use the format “Send [Message Name]” or “Receive [Message Name]” for clarity.
4. Connect tasks with choreography sequence flow: Ensure the flow reflects the required order. No loops unless explicitly agreed upon.
5. Label the flows: Add optional labels to indicate message types or conditions (e.g., “if approval is granted”).
6. Review with stakeholders: Show it to both technical and business teams. Ask: “Does this match your understanding of the interaction?”

When done right, the diagram becomes a shared contract. No more “I thought you’d send it earlier.”

Visual Example: Order Confirmation Flow

Consider this real-world scenario: a retailer and a logistics provider must agree on the order confirmation sequence.

[Retailer] → Send Order Confirmation
               ↓
[Logistics] ← Receive Order Confirmation
               ↓
[Logistics] → Send Shipment Acknowledgment
               ↓
[Retailer] ← Receive Shipment Acknowledgment
    

This is a choreography diagram. The pools are “Retailer” and “Logistics.” The tasks are the message exchanges. The flows are choreography sequence flows.

Notice: no internal steps. No gateways. No lanes. Just the agreed-upon message flow.

This diagram can be shared with both teams. It’s unambiguous. It’s contract-ready.

Best Practices for BPMN Choreography Notation

Choreography diagrams are powerful—but only if modeled clearly. Here’s what I’ve learned from years of audits and reviews:

• Use consistent naming: “Send Order Confirmation” is better than “Send Conf” or “Order Sent.” Be descriptive and unambiguous.
• Never mix choreography and process flows: Choreography sequence flows must not connect to internal sequence flows. Keep them separate.
• Use choreography tasks for all message exchanges: Even if a message is sent by a system, model it as a choreography task. The sender is still a participant.
• Keep diagrams focused: A choreography diagram should show only the message sequence. Avoid adding conditions, loops, or data elements unless essential.
• Link to other diagrams: Use choreography diagrams as a foundation. Then, build process diagrams for each participant’s internal logic.

These practices prevent confusion and ensure that choreography diagrams remain trustworthy as agreements.

Frequently Asked Questions

What is the difference between a choreography task and a message flow in a collaboration diagram?

A choreography task is a message exchange represented as a task in a choreography diagram. A message flow in a collaboration diagram shows the direction of a message between pools, but it doesn’t define the task. The choreography task is the event itself—the message being sent or received.

Can a choreography task be part of a loop?

Yes, but only if the loop is explicitly agreed upon. For example, in a retry mechanism, a participant might send a message, receive a failure, and retry. This is allowed, but it must be clearly modeled with a loop construct in the choreography sequence flow.

How do I model a conditional message in a choreography diagram?

Use a conditional choreography sequence flow. Add a label like “if payment approved” or “if data valid.” The condition applies to the message exchange, not the internal logic of the participant.

Should I use choreography diagrams for internal process documentation?

No. Choreography diagrams are for inter-participant interactions. Use process diagrams for internal workflows. Mixing them creates confusion and undermines clarity.

What tools support BPMN choreography tasks and choreography sequence flow?

Most modern BPMN tools—like Visual Paradigm—support choreography diagrams. Ensure the tool allows you to draw choreography tasks and sequence flows outside of pools, and that it validates the flow structure.

How do choreography diagrams relate to process and collaboration diagrams?

They’re complementary. A choreography diagram defines the agreed-upon message flow. A collaboration diagram shows how the message flows connect across pools. A process diagram shows what each participant does internally. Use all three to create a complete, consistent model.