BPMN: Process Orchestration vs. Choreography: Coordinating Work Within and Between Organizations - Viz Read

Introduction

Organizations rarely deliver a service through one team or system alone. A customer order, insurance claim, loan application, or employee onboarding process may involve several departments—and sometimes suppliers, payment providers, regulators, or other external organizations.

Two common ways to coordinate this work are orchestration and choreography. Orchestration coordinates activities through a central process owner or controller. Choreography coordinates independent participants through agreed interactions, without one central controller directing the entire process.

Neither approach is universally better. The right choice depends on who needs to control the workflow, how independent participants are, and what level of visibility, flexibility, and accountability the process requires. BPMN (Business Process Model and Notation) can help teams make these arrangements visible and discussable.

Key concepts

Process orchestration is a centrally coordinated workflow. An orchestrator determines what happens next, assigns or triggers work, tracks progress, and handles outcomes such as delays or failures. The orchestrator might be a person, a business process management system, or an application.

Process choreography describes the interactions between independent participants. Each participant manages its own internal work, while following shared expectations about messages, events, and outcomes. No single participant necessarily controls the end-to-end process.

A participant is a person, team, department, organization, or system involved in a process. A participant may carry out work, make decisions, or exchange information with others.

A handoff occurs when responsibility or information passes from one participant to another. Poorly defined handoffs can create delays, duplicate work, and uncertainty about who is accountable.

A process boundary separates the work one participant controls from work it does not control. This distinction is especially important between organizations: a company may coordinate its own internal steps, but it usually cannot directly command a supplier’s internal workflow.

Orchestration and choreography compared

Aspect	Orchestration	Choreography
Coordination	A central controller coordinates the sequence	Participants coordinate through agreed interactions
Process visibility	The orchestrator can often track the end-to-end flow	Each participant typically sees its own work and relevant exchanges
Control	Centralized control over progression and exceptions	Autonomy distributed across participants
Best suited to	Work with clear ownership, dependencies, and service targets	Collaboration among independent teams or organizations
Common challenge	The controller can become a bottleneck or single point of failure	Participants need clear contracts, shared meanings, and reliable communication
Typical example	A company’s system routes and tracks a customer’s loan application	A retailer, payment provider, and carrier exchange messages while each manages its own operations

These are coordination patterns, not mutually exclusive technologies. A business can orchestrate its own internal process and use choreography to coordinate with external partners.

Coordinating work within an organization

Within one organization, orchestration is often useful when activities depend on one another and someone needs to monitor the whole case. For example, an IT service request might be logged by a service desk, assessed by a support team, escalated to security if necessary, and closed after the requester confirms the fix. A workflow system can assign tasks, enforce required approvals, and track deadlines.

Choreography may fit better when teams operate with considerable autonomy. For example, a product launch may involve marketing, legal, engineering, and customer support. Each team owns its own work, but they agree on key events—such as “release date confirmed” or “customer documentation approved”—that allow other teams to proceed.

The practical question is not simply whether there is a central system. It is whether one participant is responsible for directing and monitoring the overall process. A shared calendar or messaging platform does not necessarily make a process orchestrated; a central process owner who routes work and manages exceptions is a stronger sign of orchestration.

Coordinating work between organizations

Cross-organization processes often combine both approaches. Each organization may orchestrate its internal activities, while the organizations coordinate with one another through a choreography of messages and commitments.

Consider an online purchase:

The retailer accepts an order and coordinates its own order validation.
The retailer sends a payment request to a payment provider.
The payment provider independently authorizes or declines the payment and returns the result.
If payment is approved, the retailer arranges fulfillment.
A carrier accepts a shipment request, manages delivery, and reports tracking events.
The retailer updates the customer using those external responses.

The retailer can orchestrate its own order process, but it does not normally control the payment provider’s or carrier’s internal workflows. The interaction between organizations is therefore better treated as a set of agreed exchanges: who sends what, what response is expected, what deadlines apply, and what happens if a response is missing or negative.

This boundary matters. Modeling an external partner as though it were just another internal department can imply authority or visibility the organization does not actually have.

How BPMN represents the patterns

BPMN provides a visual notation for depicting workflows, participants, and interactions. In a BPMN diagram:

Pools represent participants, commonly organizations or independent process participants.
Lanes divide responsibilities within a participant, such as departments, roles, or systems.
Tasks represent work, such as “Validate order” or “Approve refund.”
Events represent something that happens, such as a message arriving, a timer expiring, or a process starting or ending.
Gateways show branching or merging logic, such as whether payment is approved.
Sequence flows show the order of work within a process.
Message flows show communications between separate pools.

For orchestration, a BPMN model can show a coordinating process that routes work, waits for responses, and manages exceptions. For choreography, the diagram should emphasize the participants’ interactions and the messages or events exchanged between them.

A useful modeling distinction is that sequence flows stay within a pool, while message flows connect separate pools. That helps keep internal control flow separate from communication between participants.

Examples

Example 1: Employee onboarding

Orchestration: HR owns the onboarding case. Once a new hire is confirmed, HR triggers IT account setup, requests equipment, tracks required training, and follows up on incomplete tasks.

Choreography: HR, IT, facilities, the hiring manager, and the new employee each own their own activities. They coordinate through agreed events and deadlines—for example, HR sends a start-date notification, IT confirms account readiness, and the manager confirms role-specific training.

A practical choice: Use orchestration when HR must track completion and resolve delays across the process. Model team-to-team commitments as explicit interactions, even within the larger orchestrated workflow.

Example 2: Customer support escalation

Orchestration: A ticketing process assigns a new case, checks priority, routes it to the right support tier, starts an escalation timer, and tracks resolution.

Choreography: Support, engineering, and a third-party service provider coordinate through case updates and agreed response expectations. Each manages its own investigation and internal queue.

A practical choice: Orchestrate ticket ownership and service-level tracking inside the support organization. Use clear messages and escalation expectations when work crosses into teams or companies outside the ticket owner’s control.

Example 3: Insurance claim involving a repair shop

Orchestration: The insurer manages the claim case, validates coverage, requests an estimate, makes a decision, and tracks payment.

Choreography: The insurer, policyholder, repair shop, and possibly an assessor exchange information and decisions. The repair shop controls its own inspection and repair work; the insurer cannot directly dictate its internal sequence.

A practical choice: Model the insurer’s claim process as an orchestrated workflow, and represent the repair shop’s participation through messages, responses, and agreed milestones.

Choosing an approach

Use orchestration when:

One owner is accountable for the end-to-end outcome.
Work has strict dependencies or required approval sequences.
Participants need centralized status tracking, assignment, or escalation.
The process must apply consistent rules or audit controls.

Use choreography when:

Participants are independent and retain control over their own processes.
No single organization can legitimately direct the entire workflow.
Coordination depends on messages, events, and mutually agreed commitments.
Participants need room to change their internal workflows without renegotiating every step.

Use a hybrid when a central owner coordinates its own process but interacts with autonomous partners. This is common in supply chains, financial services, healthcare networks, and customer-facing digital services.

Common design pitfalls

Making the central controller responsible for what it cannot control: An orchestrator can request work or monitor a commitment, but an external participant still owns its own execution.
Leaving handoffs vague: Identify who sends information, who receives it, what response is expected, and when escalation should happen.
Modeling only the happy path: Include important exceptions such as rejection, missing information, timeout, cancellation, and retry.
Using unclear messages: Define the meaning of statuses such as “accepted,” “approved,” or “complete” so participants interpret them consistently.
Overcomplicating the first diagram: Start with the main path and major participants. Add detailed tasks and exceptions in separate views when needed.
Treating a diagram as the operating agreement: A BPMN model can clarify responsibilities and interactions, but cross-company processes may also need contracts, data definitions, service expectations, and governance.

Modeling the process with Visual Paradigm BPMN + AI

Visual Paradigm describes AI-assisted generation of BPMN diagrams from plain-language process descriptions, followed by editing in its modeling environment. Its BPMN tools also support process drill-down and documentation of working procedures. Treat the AI output as a draft to review—not as proof that the process is correct or compliant.

A practical workflow:

Write the process narrative. Name the participants, their responsibilities, the main decisions, and the events or messages that cross organizational boundaries.
Generate a first draft. In Visual Paradigm, describe the process in plain language and request the relevant pools and lanes. The exact interface and feature availability may vary by product edition.
Review the boundaries. Check that internal work is in the correct pool and that communication between participants is represented as message flow rather than internal sequence flow.
Check the logic. Confirm gateway conditions, approval and rejection paths, timers, missing-response scenarios, and end states.
Validate with participants. Ask process owners and partner representatives to confirm responsibilities, message meanings, deadlines, and exceptions.
Refine and document. Add detail where useful, attach working procedures, and maintain separate current-state and target-state versions if redesigning the process.

A useful prompt for an initial model:

Create a BPMN 2.0 process for an online order involving a Customer, Retailer, Payment Provider, and Carrier. The Retailer validates the order and sends a payment request to the Payment Provider. If payment is declined, the Retailer notifies the Customer and ends the order. If payment is approved, the Retailer sends a shipment request to the Carrier. The Carrier returns shipment acceptance and delivery-status messages. Include a timeout path when a partner response is not received within the agreed period. Separate each organization into its own pool, show internal retailer activities in lanes, and use message flows for communication between organizations.

After generation, confirm that the diagram distinguishes the retailer’s internal sequence from messages exchanged with the payment provider and carrier. Review every branch and timeout with the people who actually perform the work.

Conclusion

Orchestration and choreography solve different coordination problems. Orchestration gives an accountable owner a way to direct and monitor a workflow; choreography lets independent participants coordinate through agreed interactions while preserving their autonomy. Many real processes use both: orchestration within each organization and choreography across organizational boundaries.

BPMN makes these arrangements easier to discuss by separating participants, internal work, decisions, and messages. AI-assisted modeling can speed up the first draft, but the most important work remains human: validating responsibilities, exception paths, and the agreements that make coordination succeed.