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.

Supported HCOs

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.

Record counts

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).

Job Details

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.

Custom fields

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.

Example

	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.

Condition options

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
Fields	Losing Address 423456789012345678	Winning Address 678328123948237162	Losing Address 423456789012345678	Winning Address 678328123948237162
Address Line 1	123 Main St.	123 Main St.	123 Main St.	123 Main St.
Custom Primary	True	False	False	True
Custom Key	CRM123 (active)	CRM456 (active)	CRM123 (inactive)	CRM123 (active) CRM456 (active)
Address Status	Active	Active	Active	Active
Record State	Valid	Valid	Merged_Into	Valid

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.
Example

Field	Losing	Winning	After Merge
Address 1	123 Main St.	123 Main St.	123 Main St.
Primary__c	True	False	True

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.
Example

Field	Losing	Winning	After Merge
Address 1	123 Main St.	123 Main St.	123 Main St.
Primary__c	True	False	True

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.
Example

Field	Losing	Winning	After Merge
Address 1	123 Main St.	123 Main St.	123 Main St.
Primary__c	False	False	True

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.
Example

Field	Losing	Winning	After Merge
Address 1	123 Main St.	123 Main St.	123 Main St.
Primary__c	True	False	False (Recalculate new primary)
Record status	Active	Inactive	Inactive

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.

Example

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.

Example

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:

FILTER_INACTIVE_NETWORK_RECORDS_vod
NETWORK_ADDRESS_DELETION_PROCESS_vod__c

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.

Primary addresses

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 Primary_vod__c = True.

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.

Refreshing subscriptions

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:

geo_subdivision__v
geo_subdivision_label__v
geo_subdivision_2__v
geo_subdivision_2_label__v

For more information, see the Geo Subdivision data topic in the Veeva Network Online Help.