Resolving duplicate primaries

AD
DM

When primary type fields are configured, one object can be primary for different fields. For example, Global Primary Address and Primary Address for Cardiology can be set to Yes/True for the same address. But, a primary field can be set to Yes/True for only one set of objects. For example, an HCP cannot have the Primary Address for Cardiology field set to Yes/True for two different addresses.

Duplicate primaries in the Network UI

To ensure that there are no duplicate primaries, Network changes the primary value if the field is set to Yes/True multiple times across an object.

Example

All users can edit primary fields on record profiles. If the primary field is updated, a data change request is created and sent to local data stewards to accept or reject the change.

To ensure that a field is set to primary on only one object, Network changes the primary value if a field is set to Yes/True multiple times on a record.

Example

On an HCP record, the Primary Address for Cardiology field is set to Yes/True for 6941 W Archer Ave.

A user edits the record and sets the same primary field to Yes/True for 1180 W Wilson St Ste E.

To ensure that there's only one Primary Address for Cardiology defined on the record, Network automatically toggles the field value to No/False on the 6941 W Archer Ave address.

The same behavior occurs on data change requests.

Multiple primaries on entity merge, unmerge, and Change Request API

If multiple primaries are defined on an object (for example, the Primary for Cardiology field is set to Yes/True on more than one address), the primary will be determined by Network for one object only using the following criteria:

  • Source rank
  • Last updated time
  • Network entity ID

Review the following diagram to understand how primary is determined on merge, unmerge, and changes submitted using the Change Request API.

In the Change Request API, even if a primary field is set for multiple objects, only the changes are read. So if the primary does not change on an object, the value is not acknowledged.

In Network Change Request API Result
Change Request API - Update 1
  Address1: primary = Yes

Address2: primary = Yes 		Address1: primary = No, VID = 123

Address2: primary = Yes, VID = 456
Change Request API - Update 2
Address1: primary = No

Address2: primary = Yes 		Address1: primary = Yes

Address2: primary = Yes 		Address1: primary = Yes, VID = 123

Address2: primary = No, VID = 456
Change Request API - Update 3
Address1: primary = Yes

Address2: primary = No 		Address1: primary = Yes

Address2: primary = Yes

Address3: primary = Yes 		Address1: primary = No, VID = 123

Address2: primary = No, VID = 456

Address3: primary = Yes, VID = 789

Results

  • Update 1 - Address2 is set to primary because it has the highest ordinal.
  • Update 2 - The primary moves because the current primary value (Address 2) did not change, only the second primary (Address1) changed. In the Change Request API, only changes are read, so Network does not see the primary value from Address2.
  • Update 3 - There were two changes in the Change Request API: Address2 and Address3. Address3 is set to primary because it has the highest ordinal.

OpenData address merge behavior on the same entity

If OpenData merges addresses on the same entity, the primary address will be retained on the winning address and no primary re-calculation occurs.

Multiple primaries on source subscriptions

When multiple primaries are available in a source file, all of the primary values are read and the source file changes are compared with the data that is already in the Network instance.

In Network Change in data load Result
Source file - Update 1
  Address1: primary = Yes

Address2: primary = Yes 		Address1: primary = No, VID = 123

Address2: primary = Yes, VID = 456
Source file - Update 2 (no change in source file)
Address1: primary = No

Address2: primary = Yes 		Address1: primary = Yes

Address2: primary = Yes 		Address1: primary = No, VID = 123

Address2: primary = Yes, VID = 456
Source file - Update 3 (change in source file)
Address1: primary = No

Address2: primary = Yes 		Address1: primary = Yes

Address2: primary = Yes

Address3: primary = Yes 		Address1: primary = No, VID = 123

Address2: primary = Yes, VID = 456

Address3: primary = No, VID = 789

Results

  • Update 1 - Address2 is set to primary because it has the highest ordinal.
  • Update 3 - There were two changes in the data load: Address1 and Address3. Network sees all of the primary values in the source file and compares them to the existing values in the Network instance. Because Address2 was already set as primary, to prevent flip-flopping, the primary does not move.

Merging and unmerging records

When records are merged, a primary custom field might be set to Yes/True multiple times across one set of objects. For example, both records that are being merged might have the Primary Address for Cardiology field set to Yes/True for an address. Network ensures that the surviving record has only one primary for that field.

Primary rules for merging records:

  • If an object is primary on the winning record, the winning record's primary object remains primary on the merged record.

  • If an object is primary on the losing record, and the winning record has no primary specified, the losing record's primary object will be primary on the merged record.

  • If OpenData or third party managed records are merged with customer records and an OpenData or third party managed address is primary, it always wins.

The example applies to customer (gray to gray) records or Veeva OpenData (orange to orange) records.

Primary value on winning record

280 Bay Street W 		Primary value on losing record

280 Bay Street W 		Primary value on the merged address
No Value No Value 280 Bay Street W - No Value
Yes/True No/False 280 Bay Street W - Yes/True
No/False Yes/True 280 Bay Street W - No/False
No Value Yes/True 280 Bay Street W - Yes/True
Yes/True Yes/True 280 Bay Street W - Yes/True

The example applies to customer (gray to gray) records or Veeva OpenData (orange to orange) records.

Primary value on winning record

208 Bay Street W		 Primary value on losing record

74 Victoria Avenue		 Primary value on merged addresses
No Value No Value 280 Bay Street W - No Value

74 Victoria Avenue - No Value
Yes/True No/False 280 Bay Street W - Yes/True

74 Victoria Avenue - No/False
No/False Yes/True 280 Bay Street W - No/False

74 Victoria Avenue - Yes/True
No Value Yes/True 280 Bay Street W - NoValue

74 Victoria Avenue - Yes/True
Yes/True Yes/True

The winner's address will be primary.

The example applies to merging customer to Veeva OpenData records (gray to orange) records or merging customer to third party (gray to blue) records.

Primary value on winning record (master)

208 Bay Street W 		Primary value on losing record (customer)

208 Bay Street W 		Primary value on merged address
No Value No Value 280 Bay Street W - No Value
Yes/True No/False 280 Bay Street W - Yes/True
No/False Yes/True 280 Bay Street W - No/False
No Value Yes/True 280 Bay Street W - Yes/True
Yes/True Yes/True

280 Bay Street W - Yes/True

This example applies to merging customer to Veeva OpenData (gray to orange) records or merging customer to third-party (gray to blue) records.

Primary value on winning record (master)

280 Bay Street W 		Primary value on losing record (customer)

74 Victoria Avenue 		Primary value on merged addresses
No Value No Value 280 Bay Street W - No Value

74 Victoria Avenue - No Value
Yes/True No/False 280 Bay Street W - Yes/True

74 Victoria Avenue - No/False
No/False Yes/True 280 Bay Street W - No/False

74 Victoria Avenue - Yes/True
No Value Yes/True 280 Bay Street W - No Value

74 Victoria Avenue - Yes/True
Yes/True Yes/True

280 Bay Street W - Yes/True

74 Victoria Avenue - No/False

Unmerging records

When records are unmerged from each other, any fields that were set as primary on the original records are recovered.