Veeva OpenData subscriptions
OpenData fields for new instances
All Veeva OpenData fields are now mastered by default in new Network instances. Previously, all OpenData fields were enabled in new instances; now, they will also be mastered by the respective OpenData country. This update simplifies the data model configuration in new instances.
In your Veeva OpenData country subscription, all fields will be included in the Selected Fields section.
This enhancement is enabled by default for all new Network instances.
Download related HCOs
Administrators and data managers now have the option of downloading Parent HCOs that are related to the OpenData HCOs and HCPs that are already downloaded to their Network instance. When Veeva OpenData country subscriptions run, parent HCOs are not downloaded; parent HCOs are only downloaded during ad hoc download jobs. This enhancement gives you the option to download those missing Parent HCOs so you have complete relationships in your instance. The count of related HCOs is provided so you will know how many records you can expect to be downloaded.
This enhancement is available in your Network instance by default. You can use these settings in new and existing country subscriptions.
The parent HCOs that can be downloaded must meet the following requirements:
- The record state is Valid
- The record status is Active
Note: HCOs that have been previously unsubscribed can be downloaded as a new record if they are related to an existing HCP or HCO.
HCOs will not be downloaded in the following situations:
- The related HCP is opted-out
- The country of the HCO is different from the related record
Download missing parent HCOs
A section called Additional OpenData Parent HCO records is added to the country subscription. You can choose to download parent HCOs that are related to HCPs and/or HCOs.
Network displays the number of parent HCO records that will be downloaded the next time the country subscription runs. Click the Info icon beside the setting to see an estimated count of records.
This count doesn't consider any filters that you might have applied to HCOs for this subscription, so after the job runs, the count of records in the Job Details might be different.
Only the first level of a hierarchy is included in the count. If the checkbox for HCOs remains selected, one level of parent HCO will be downloaded each time the job runs until all of the parent HCOs in a hierarchy are downloaded.
After the job runs, the count is reset to zero (0).
About the job
The parent HCOs will be downloaded in a separate job that is triggered after the regular Veeva OpenData country subscription runs. The Download Related HCOs job runs once even if you check both the HCP and the HCO options.
Any HCO filters that you have defined in the country subscription are used to filter the parent HCO records, but the setting, Level of parents to download, is not used for this job; only one level in the hierarchy is downloaded.
If the subscription does not run because there are no new or updated records to download for that country, the Download Related HCOs job does not run (even if there are parent HCOs to be downloaded).
Note: Reporting must be enabled in your Network instance for this job to run (Settings > General Settings).
On the country subscription's Job Details page, the Download Related HCOs job is listed in the Job Trigger Summary section. The job is automatically triggered when the country subscription runs; it cannot be managed as a typical job trigger and isn't listed on the List of Job Triggers page (System Interfaces).
Click the Job ID to view a final count of the HCO records that were downloaded.
Merged addresses from Veeva OpenData
Starting September 25, 2020, Veeva OpenData (US) will begin to periodically run bulk merge jobs if duplicate addresses are discovered in the master instance. Updates to addresses will flow down to your Network instance whenever your OpenData subscription runs or you sync or download records from OpenData. This applies only to your Veeva OpenData US subscriptions.
Merging duplicate addresses keeps your data quality high, but it can impact your data depending on the Network features that you use for your business processes. Review the potential impacts and methods of preserving your data.
Standard bulk merge behavior
During a bulk address merge, Network automatically performs these actions to preserve your data:
- Record state - The state of the losing address changes to Merged_Into.
Custom keys - Keys from the losing address are moved to the winning address (so you have a reference to the losing record).
This means that the winning address will have two active custom keys.
Custom fields - Fields will go through survivorship.
If custom merge rules are defined for a field, they determine survivorship on the winning address; otherwise, source survivorship is used to determine the value on the winning address. String fields (not supported for custom merge rules) always go through source survivorship.
- Licenses - Any licenses on the losing address are redirected to the winning address.
Merge behavior that can impact data
There can be some unintended impact to your data after a merge depending on the Network features that you use.
The following behavior can occur:
- Custom field value survivorship - Source survivorship determines the values on the winning record, so specific values can be lost if custom merge rules are not defined for the fields.
- Primary address moves - Depending on your primary address configuration, the primary will be updated to the deduplicated winning address.
- Inherited addresses become inactive - An existing locally managed copied address that points to a Merged_Into address will be unsynced (disqualified) and inactivated.
- Unsynced inherited addresses remain unsynced - If you make changes to a copied Veeva OpenData address (so the address becomes unsynced from the HCO) and Veeva OpenData merges that address into a winning address, when you sync with OpenData to get updates, the copied address remains unsynced. It cannot be synced again because the parent address is now a Merged_Into address.
For more details, review the following sections.
When addresses are merged, source survivorship determines the field values that are retained on the winning record. You might have specific values (from either the winning or losing record) that you want to be retained. For example, if you have a custom field to track shipping address for an HCP, you might want the reference value, Y (Yes/True), retained over other values (False or Unknown) so your operations teams know where to send samples for that HCP. When addresses are merged, source survivorship determines the value, so the Y value could be lost.
|Losing Address||Winning Address||After Merge|
|Custom field and value||Shipping Address = Yes/True||Shipping Address = Unknown|
|Using Source survivorship||Source Ranking = 3||Source Ranking = 1||Shipping Address = Unknown|
|Using Custom Merge Rule||Reference Code Ranking = 1||Reference Code Ranking = 3||Shipping Address = Yes/True|
Use custom merge rules to ensure that field values are not lost or overwritten during the merge. Custom merge rules can be created so you can define the condition to keep specific values.
|Field Type||Winning Condition Options|
|Integer/Decimal Number||Highest Value Wins / Lowest Value Wins|
|Date||Most Recent Wins / Oldest Value Wins|
|Checkbox (reference with Boolean Reference list)||True Wins / False Wins|
|Reference Fields||Upload the list of fields.
Rank the reference codes for survivorship and then upload the edited file back into Network.
Note: Custom merge rules are not supported for Text type fields. Text fields will go through source survivorship.
For more information, see Custom merge rules.
Custom primary field
Primary custom fields are used to designate a "best" address for specific uses. A primary custom field can use one of the following configurations:
- Network Calculated - Network automatically determines the primary based on specific criteria.
- Unique Checkbox - The primary does not move unless you move it. Additional options are available for allowing Network to calculate the primary for specific conditions.
Primary address calculation can initially be populated during a data load or when new records are created and downloaded from Veeva OpenData. Subsequent updates depend on the primary address configuration and can be triggered when records are synced with Veeva OpenData.
Standard primary behavior
In all configurations, if the losing address is primary before the merge, the primary value moves to the winning address. This ensures that the primary is preserved on the merged address. When the primary custom field value is Yes/True on the winning record, merging the addresses does not move or change the primary value.
|Before Merge||After Merge|
|Address Line 1||123 Main St.||123 Main St.||123 Main St.||123 Main St.|
|Custom Key||CRM123 (active)||CRM456 (active)||CRM123 (inactive)||CRM123 (active)
For more information primary address calculations, see Unique Checkbox with primary address calculation options in the Veeva Network Online Help.
Primary behavior when primary is on the losing address
Review the tables for each primary configuration type to understand how merging addresses can impact the primary when the primary custom field is Yes/True on the losing address.
|Network Calculated||Behavior during merge|
|The primary moves to the winning address.
The Unique Checkbox configuration includes options so you can control the behavior of the primary flag.
|Unique Checkbox||Behavior during merge|
|No options selected||The primary moves to the winning address.
|The record DOES NOT HAVE a primary address||If the losing address was not primary, a primary will be calculated as usual to ensure that the record has a primary address.
Note: If the primary is on another address on the record, there is no change to the primary address.
|The status of the primary address is INACTIVE||The primary moves to the winning address.
However, if the winning address is inactive, the primary will be recalculated and moved to another address on the record. If there are no other addresses, the record will not have a primary address.
This can impact any business processes that rely on the primary staying on that address, or the record having at least one primary address.
|The record state of the primary address is INVALID or DELETED||Does not apply. An address cannot be merged into an invalid or deleted address.|
For more information about primary custom fields and behavior, see Primary address.
Network address inheritance
Inherited addresses become inactive
Network address inheritance links addresses on parent affiliations to child affiliations to improve the quality of the address data and to simplify address management. When address inheritance is configured, fields are copied from the parent address but custom fields can be populated by local data stewards or source subscriptions.
After addresses are merged on the parent affiliation in OpenData, the existing link between the affiliations is not updated; the losing address is disqualified and becomes inactive. A new link is created to the winning address with a new Network entity ID (VID) if the winning address is not already copied on your Network instance.
Unsynced inherited addresses remain unsynced
After addresses are merged in the Veeva OpenData master instance, an existing unsynced address in your local instance can remain unsynced.
This occurs if you make changes to a copied Veeva OpenData address and then Veeva OpenData merges that address into a winning address. When you sync with OpenData to get updates, your copied address will remain unsynced. It cannot be synced again because the parent address is now a Merged_Into address.
You have an HCP (Veeva or locally managed) that is affiliated to an OpenData HCO. Using Network Address Inheritance, you've copied the HCO address down to the HCP.
A change is made to the copied address on the HCP, so the copied address becomes unsynced; the value of the
parent_address_sync__v field on the copied address is U (Unsynced).
Veeva OpenData merges the HCO addresses and the copied address on your HCP is the losing address in the merge. When you sync with OpenData to get updates, the copied address will remain Unsynced. If you try to resync the copied address, it still remains Unsynced because that parent address is now Merged_Into.
Veeva CRM considerations
When losing addresses are exported to CRM, they might be deleted if you have the following CRM settings enabled:
When addresses are merged in Network, the record state of the losing address changes to Merged_Into. Depending on your setting values for these CRM options, addresses that do not have a Valid or Under_Review record state can be deleted (the custom keys are still moved to the winning address). This means that Merged_Into addresses will not display in CRM, but call information associated to the losing address will remain stamped on the call record.
To review the behavior of the setting values, see the Handling inactive records topic in the Veeva CRM Online Help.
Review the field mappings between CRM and Network to ensure that any custom fields in CRM that should be carried over to the winning address are mapped to Network, including the
Primary_vod__c field. For more details, see Network field mapping in the Veeva CRM Online Help.
If you maintain primary flags in Veeva CRM by using
Primary_vod__c and it is not mapped to Network, when addresses are merged and you receive updates through the Network Bridge, Network ensures that the primary address is retained in the following situation:
- The address merge occurs on the same entity (HCP/HCO).
- The losing address has
In these situations,
Primary_vod__c is set to True on the winning address.
Testing data impact to downstream systems
Using your Sandbox instance, you can test how address merges from OpenData might affect data in your downstream systems. For more information, contact Veeva Support.
When you update a subscription to add HCP or HCO filters, you can now choose to download any additional records that meet the new filter criteria the next time the job runs.
By default, when you add HCP and HCO filters, new records that match the criteria are downloaded only when OpenData makes changes to the record. Now, the next job that runs can include any new records along with updates to existing records.
After you apply new HCP or HCO filters and click Save, a pop-up displays to confirm your changes. By default, the option to download additional records is selected. Clear the option if you do not want the next job to include all of the records that meet your new criteria.
Changes that were made to additional subscriptions (for example, HIN data or Email) and any changes to fields are also confirmed in the pop-up.
Before the next job runs, a message displays at the top of the subscription to notify users that the HCP/HCO filters have been changed and additional records may be downloaded.
Country subscriptions for all records
If you purchase all OpenData records for a particular country and you have specifically requested to have all records downloaded to your instance, the country subscription page now indicates these details.
The subscription is also updated to remove the section for the Working Set and the Health Care Professional and Health Care Organization sections to subscribe to additional records. When you subscribe to have all records downloaded to your Network instance for a particular country, there is no need to maintain a working set or HCO/HCP filters.
You can continue to manage the parent HCOs that are downloaded, additional field level subscriptions (for example, Email and Geo Subdivision), and Veeva OpenData fields.
Geo Subdivision subscriptions
The Geo Subdivision and Geo Subdivision 2 subscriptions are now available for Russia. These subscriptions contain sales data that is organized into small geographic areas.
If these subscriptions are added to your OpenData subscription for Russia, the following fields are automatically enabled on address object:
For more information, see the Geo Subdivision data topic in the Veeva Network Online Help.