The data hub is aimed at managing entities which track versions and provenance. This uses standard fields, and a standard method of coding "soft" deletes.
In some cases, it is useful to export data to data structures that don't track versions or provenance, and which use real deletes, for example for reporting. The data hub terms these export entities.
Export entities may not support read operations, depending on their definition.
Set the Export indicator to indicate that this is an export entity.
Set the Export standard fields indicator to export standard fields (guid, valid_from_timestamp, valid_to_timestamp, deleted_indicator, source_message and field_provenance). In many cases this won't make sense, and so this defaults to false. If you build the data for the export from a query you might take some of these fields from the source, to provide traceability. If you export standard fields, read operations might work, depending on the type of data store you are using.
If writing to a data structure that uses some form of record id (like Elasticsearch), use Export id to specify how the id should be built. It's use is implementation dependent. For Elasticsearch, enter the name of a field that will hold the Elasticsearch document id. If you don't enter a field, a combination of the guid and valid from timestamp will be used. However, these are only available if exportStandardFields is set to true, and you must set either the Export id or Export standard fields with Elasticsearch.