Data Store
A persistent data repository — database, archive, system of record — that outlives process instances and is shared between them. Cylinder shape.
The Data Store is where information survives: instances come and go, but the customer database remains. Activities read from and write to it through dotted data associations, documenting the process's touchpoints with systems of record.
When to use and avoid
When to use
To show reads/writes against systems of record (CRM, ERP, archives).
When several instances or processes share the same information.
To document integration points for compliance and impact analysis.
When NOT to use
For instance-local working data — Data Objects.
To model the system's behavior — the store is a passive repository, not a participant; if it acts, give it a Pool.
As a message channel between participants — that is what Message Flows are for.
Business example
Writing to the customer database
Open this example in the HEFLO process editor and explore the diagram from the inside.
Open in the HEFLO editor →Step by step
- Update customer record writes to the Data Store “Customer database” (highlighted, cylinder) via the dotted association.
- The store persists beyond this instance — tomorrow's processes will find the updated record.
- The flow continues to confirm the update; the store stays available to every other process.
Differences
Data Store vs black-box Pool
A store is passive data the process reads/writes. A black-box Pool is an active participant that exchanges messages. If the 'database' actually validates, responds and decides — it is a system participant, not a store.
FAQ
Do stores belong to a Pool?
Data stores are global to the collaboration — visible to any process — which is exactly what shared persistence means.
Read vs write — how are they told apart?
By the association direction: store → activity is a read; activity → store is a write.