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 |
Primary behavior when primary is on the losing address
Review the table 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
|
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
|
||||||||||||||||
| 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
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
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.
