Sources of data
Within your Network instance, you can have data from multiple sources. This provides you with the flexibility to purchase data for specific countries or entity types, or to maintain your own data.
Veeva OpenData content is purchased from and maintained by Veeva. In the Network UI, this data is identified by orange icons and fields.
You can subscribe to Veeva OpenData for any country where Veeva OpenData is provided. Veeva OpenData is loaded into your Network instances using subscriptions and ad hoc downloads. For more information, see Veeva OpenData subscriptions.
Add requests can be routed to Veeva OpenData if you have a subscription for the primary country of the new record. Network users can send change requests for the data provided to them and Veeva data stewards validate and update that data accordingly.
Third party data
Third party data is purchased from an external source. In the Network UI, this data is identified by blue icons and fields.
Third party vendors typically provide customers with stewardship services, so changes to data are routed to third party data stewards for validation and processing. Third party master data is never used to improve Veeva OpenData.
Data from third party sources is loaded into your Network instance using source subscriptions. When you create a system, you can define the DCR routing criteria by country, entity type, and fields.
Local data is created within your Network instance or is purchased from a source and is mastered by local data stewards. In the Network UI, this data is identified by gray icons and fields (green icons and fields in China).
Locally managed data is loaded into your Network instance using source subscriptions and add requests.
Types of locally managed data
For data privacy, locally managed data that is loaded from source systems can be identified as proprietary and/or restricted data. These flags can be selected when administrators create the system in Network.
Additionally, for contact organizations, data can be defined as externally mastered using the
is_externally_mastered__v field. The externally mastered field is typically used with proprietary data sources.
|Restricted||System setting (System Interfaces > Systems)||Data loaded into Network using the system is flagged as restricted.|
|Proprietary||System setting (System Interfaces > Systems)||Data loaded into Network using the system is flagged as proprietary.|
|Externally mastered||Data model field||Enable the field in your Network instance and include the field in your source file.|
Information about the source and its contributions to a particular record (data lineage information) cannot be viewed by Network users unless they have explicit permission through their data visibility profile. Restricted systems can be proprietary or non-proprietary.
The proprietary flag applies to data change requests only. Defining local data as proprietary ensures that add and change requests that are submitted through the Network API will not be sent to Veeva OpenData.
The proprietary flag is specific to API calls because it depends on the system parameter being specified in the DCR. Data stewards working in the Network UI are not using any system, so any changes they make will be sent to Veeva OpenData; for example, adding a new HCP or editing a Veeva-mastered field (the first name of an HCP). These changes will be sent as a DCR to the Veeva OpenData team. Any changes that data stewards make to customer data will not be sent to Veeva OpenData.
Proprietary settings are tracked by system rather than field. The
is_proprietary__v data model field is not being used in Network currently but displays in the Record Information section of a record profile if enabled. Regardless of whether this field is enabled in a record profile, its value is ignored; the record's proprietary status is strictly determined by the system that provided it.
Externally mastered data
is_externally_mastered__v field can be used to identify contract organization records; records that contain legal and other data and that should not be updated by other data sources or even viewed by most users. This field is typically used with proprietary sources for legal reasons.
Defining externally mastered records
is_externally_mastered__v field must be enabled in the data model and added to the source file for your source subscription. To flag records as externally mastered, set the value of the field to Y (Yes/True) in the source file. Run your source subscription (for example, the subscription for your proprietary system) to load the data into Network.
If records are loaded before the field is enabled, the data will not be secured from updates and merges. Similarly, if the field is enabled and included in the source file but then the field is disabled after the data is loaded, those records will not be considered externally mastered.
Externally mastered record behavior
is_externally_mastered__v field is used for logic in match rules and data visibility profile permissions.
When records are flagged as externally mastered in data loads, the following behavior occurs:
- Network retains all sub-object data on data load (for example, Network does not deduplicate or cleanse addresses).
- Records cannot be updated or merged with Veeva OpenData.
- Records can be filtered from target subscriptions so they are not sent to downstream systems.
- Records are restricted from users through data visibility profiles. The Can Search Contract Organizations permission must be enabled for users to see these records.
- Addresses are not cleansed by Network's third party cleansing service.
- Records should be updated only by the original source system using data loads. Any other changes will be overwritten by source updates.
Data management for record types
Records can contain data from different sources. On the Profile page, users can view all types of records and can identify ownership of the data from the colors of the fields on the record: orange (Veeva OpenData), blue (third party source), gray (locally managed), green (locally managed for China). When users add or update data, the change requests are routed to the appropriate source for verification and processing.
The source of the record can determine the specific behavior for some Network features.
|Locally Managed||Third Party||Veeva OpenData|
|Record data (viewed on Profile page)||Records contain locally managed data only.||Records can contain third party and locally managed data.||Records can contain locally managed and Veeva OpenData data.|
|Data change requests (DCRs)||DCRs are routed to local data stewards.||DCRs are routed to third party or local data stewards based on field ownership.||DCRs are routed to Veeva OpenData or local data stewards based on field ownership.|
|Matching and merging records||
Locally managed records can be matched and merged with third party and Veeva OpenData records. Source survivorship rules determine the fields that win in a merge. If you do not want records to be matched with master records, you can add restrictions using the match rules.
Note: If proprietary records are flagged as externally mastered, those records will not be matched or merged.
Locally managed records can be matched to third party records. Third party records always win.
Third party data cannot be matched with other master sources.
Suspect match is not permitted with local or Veeva OpenData records.
Locally managed records can be matched to OpenData records. Veeva OpenData always wins.
Suspect match is not supported in customer instances for Veeva OpenData records.
|Match against OpenData||Yes||
Note: Proprietary records that are flagged as externally mastered will not be matched.
|Yes||No. This option does not display in source subscriptions for third party systems.||Not applicable|
|Send to OpenData||Yes||No - if one source contributing to the record is flagged as proprietary, this option is not available on the record.||No||No - third party records are never sent to Veeva OpenData.||Not applicable|
Note: Proprietary records that are flagged as externally mastered will not be deduplicated.
Note: Address cleansing is not applied to locally managed records that are flagged as externally mastered.