# Data Exchange between BPMN Processes

**In short:** Separate BPMN processes sit in separate pools. They exchange data in two ways: messages sent across pools, or a shared data store that one process writes and another reads. The store keeps writer and reader independent.

## Explanation

A BPMN collaboration diagram shows how two or more business entities interact (see the article BPMN Collaboration Diagram). Each entity gets its own pool. A pool stands for a major participant, often a separate organization (see BPMN Swimlane (Pool and Lane)).

**Message flows connect pools.** A message flow can never link elements inside the same pool. That makes it the connector between pools. Each message has exactly one sender and one recipient.

**Events carry the signal.** A process can have one or more message start events. Deploying the process creates a message subscription for each one. An intermediate message catch event also creates a subscription when the process reaches it, so the instance waits there until the message arrives.

**Data stores hold shared data.** A data object shows the reader which data an activity needs or produces. A data store is the shared place where data is kept. One process writes data into it. Another process reads it later. This follows the Shared Database style: applications integrate by keeping their data in one common database (see Shared Database). The store decouples writer and reader. Neither needs to know when the other runs.

**A timer can start the reader.** A timer start event creates a new process instance each time the timer fires. It needs a date or a cycle definition, and deployment schedules it. This lets the reader check the store on a schedule, in a polling style (see Polling Consumer).

**Tool support varies.** Camunda supports data stores and data objects for modeling only, not for execution. A diagram can show the store, but the engine will not read or write it for you.

## Example

An online shop has two pools. The "Order intake" pool saves each new order to an orders store. A separate "Reporting" pool starts every night from a timer start event. It reads the orders store and builds a sales summary. Intake never calls Reporting. If Intake needs to tell Reporting something directly, it sends a message across the pools.

## Trade-offs

A shared store keeps writer and reader independent, but it needs a schema that suits every user. Designing that shared schema is one of the biggest difficulties of the Shared Database style. Messages are different: each goes from one sender to one recipient, so they fit a signal for a single receiver. Because Camunda treats stores as modeling-only, the diagram documents the data exchange but does not run it.

BPMN diagram: [Two pools: the writer saves data to a store, and a timer-started reader process reads it.](https://arc.fuet.ch/diagrams/concepts/modeling-bpmn/data-exchange-between-bpmn-processes/diagram-1.bpmn)

## Checks

- Processes run by different participants are modeled in separate pools, and message flows (not links inside one pool) connect them.
- Each message has a single sender and a single recipient.
- A reader process that polls a shared store has a timer start event with a date or cycle definition.
- The shared schema of a data store used by several processes is designed and documented.
- Where Camunda is used, the document states that data stores and data objects are modeling-only and not executed.

## Related

- [BPMN Collaboration Diagram](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-collaboration-diagram.md)
- [BPMN Swimlane (Pool and Lane)](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-swimlane-pool-and-lane.md)
- [BPMN Data Element](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-data-element.md)
- [Shared Database](https://arc.fuet.ch/concepts/integration/shared-database.md)
- [BPMN Event](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-event.md)
- [Polling Consumer](https://arc.fuet.ch/concepts/integration/polling-consumer.md)
- [BPMN Connecting Object](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-connecting-object.md)
- [Integration Styles](https://arc.fuet.ch/concepts/integration/integration-styles-overview.md)

## Sources

- [Business Process Model and Notation - Wikipedia](https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation) — en.wikipedia.org, accessed 2026-11-08
- [Shared Database - Enterprise Integration Patterns](https://www.enterpriseintegrationpatterns.com/patterns/messaging/SharedDataBaseIntegration.html) — enterpriseintegrationpatterns.com, accessed 2026-11-09
- [Message events | Camunda 8 Docs](https://docs.camunda.io/docs/components/modeler/bpmn/message-events/) — docs.camunda.io, accessed 2026-11-09
- [Timer events | Camunda 8 Docs](https://docs.camunda.io/docs/components/modeler/bpmn/timer-events/) — docs.camunda.io, accessed 2026-11-08
- [BPMN coverage | Camunda 8 Docs](https://docs.camunda.io/docs/components/modeler/bpmn/bpmn-coverage/) — docs.camunda.io, accessed 2026-11-09