Merging and unmerging records

When records are merged either during a data load or manually by a data steward, information on the source records is retained for future use, such as a subsequent unmerge.

A merge operation creates a new record from multiple source records based on survivorship The process by which the final record is determined as duplicate records are merged, resulting in winning and losing values. rules defined by your administrator (which consider the source system, and individual entity and field rankings). Values from the source records are retained, while the records themselves are inactivated.

An unmerge operation effectively creates new records from each of the source records that comprised the final record. These records are considered new, independent records to downstream systems such as CRM. The influence of the unmerged source records is removed from the original record completely; related sub-objects (addresses, relationships, and licenses) move with the unmerged records.

Note: Unmerge is not a rollback or “undo” operation; The latest version of the source records is used to re-evaluate survivorship. Change requests for the original Network record are not re-applied.

The Data Lineage page for a merged record displays information on the source records that contributed to the final record.

Veeva OpenData records

The following apply when merging or unmerging records from Veeva OpenData:

• Customer data stewards cannot request merges for Veeva-owned (orange) records.
• When customer (gray) and Veeva (orange) records are merged, the Veeva values (for example, first and last name) always survive.
• If a customer record contains information that a Veeva record does not contain (such as an address or parent HCO) that information is added to the record if the subscription that loaded the data is set to enable sub-objects. Sub-objects loaded in this way are not sent to Veeva data stewards for validation, and are not shared with other Veeva data (that is, they do not become part of Veeva data).

Merge/unmerge example

Two records are considered a match, one locally managed and one OpenData managed. They both have a record state An attribute in the data model that tracks the general state of a record, for example UNDER REVIEW, VALID, INVALID, MERGED. of Valid, and have their own Veeva IDs. The local record has a custom key, while the OpenData record does not.

Upon being merged, the record state of the losing (local) record changes to Merged Into, while the record state of the winning (OpenData) record remains Valid. The local record is updated with a Survivor VID referencing the Veeva ID of the winning record, and its custom key state has been changed to Inactive.

This information appears in the data lineage A detailed view of the current record, including all sources that contributed to it and survivorship results at the field level..

When these records are unmerged, a new record is created with a new Veeva ID and the original custom key of the local record. The custom key status is changed to Inactive on the Veeva owned record.

Unmerging without source keys

Depending on source system configuration, unmerging may take place without source keys being retained; for example, from CRM systems that don't otherwise support unmerge.

In these circumstances, two completely new records are created without custom keys (or any references to them). Any link to the original record is lost. For more information on configuring systems, see Adding systems.

About custom keys and Veeva IDs

The custom key on a record is a cross reference to an external system ID, whereas a Veeva ID uniquely identifies a record within Network. Custom keys are loaded from a data source, while Veeva IDs are generated automatically.

During a merge or unmerge, the custom key moves with its corresponding record. Veeva IDs do not move with records; New Veeva IDs are created during this process. Custom keys are always associated with the latest and complete Veeva OpenData record, while VIDs may be associated with out-of-date, merged, or deleted records.

Custom keys are associated with source information in the data lineage for a record.