Ivo Velitchkov made me pay attention to the difference between BPMN 1.x и BPMN 2.0 in respect to data flow modeling.

Data exchange in BPMN 1.x is modeled with Data Objects:

Fig. 1 Data Objects in BPMN 1.x

BPMN 1.x Data Object is an artifact used to inform what a process does. With the help of Association it may be linked to a Task, Control Flow or Message Flow yet it won’t directly affect any of them.

Data Objects can model a range of physical or electronic objects. We may for example drop a Data Object outside a pool and label it “Orders Database” in order to model interprocess communications via data.

Yet as Ivo rightfully pointed out the diagram depicted above becomes illegal under BPMN 2.0!

The point is that Data Object is associated with a process context in BPMN 2.0: it is drawn within a process (subprocess) boundary and it only exists from a process (subprocess) instance start to end. Therefore it can’t be accessed from the external process.

Persistent data not tied to a process lifecycle are modeled with Data Store, so this element should be used to model interprocess communication via data in BPMN 2.0:

Fig. 2. Data Objects and Data Stores in BPMN 2.0

As a side note, BPMN 2.0 makes a difference between single-item data objects and collections - the latter carry a special marker. It also introduces special markers for Data Inputs and Data Outputs and new elements - Input Sets and Output Sets.

BPMN 2.0 also defines Data Association in addition to the general Association inherited from 1.x. While general Association serves documenting purposes only, the Data Association is “executable”: one may define source, target and optionally transformation at the model attribute level. One may define right at the model the data manipulations that should be performed at activity start and end, message send and receive. Visual representation remains the same: dotted line with V-shaped arrow.

BPMN 2.0 specification is slightly controversial with respect to Data Association:

• P.221 says that Data Association is used with Data Objects without mention of Data Stores. Since Data Objects always belong to a process, one may conclude that Data Associations should never cross a pool border. This rule would make the second diagram illegal - please refer to Ivo Velitchkov’s comment.
• Yet p.208 says clearly that Data Store may serve as input or output for a Data Association.

So I believe that the diagram at fig.2 is valid.

Besides, even if you or your tool has objections against using Data Associations with Data Stores then you still can use plain old Associations that look exactly the same.