Unique Checkbox primary fields

Administrators and data managers can create multiple primary type custom fields and configure them so that they are managed by Network users. This provides flexibility for customers who rely on a static primary in a fiscal quarter for their business processes. For example, primary custom fields can be created for different business units based on therapeutic areas, so different HCPs might have primary addresses for oncology, pediatrics, and cardiology.

When primary custom fields are managed by users, the primary setting does not move from the object unless it is changed by a user. This behavior ensures that customers can rely on the primary designation for business processes like territory alignment and compensation.

Supported objects

The Unique Checkbox configuration is available on all Network and custom sub-objects and relationship objects. The information in this topic can be applied to any object that you use with the Unique Checkbox primary field configuration.

Addresses

For all other objects, using the Unique Checkbox primary field means that Network will not move the primary setting. However, for address objects only, you can allow Network to calculate the primary for specific situations. The configuration provides options that you can choose depending on your needs.

To use this primary field configuration for addresses, see the detailed instructions in Unique Checkbox primary addresses.

The information in the sections below applies to addresses that do not use any of the Unique Checkbox configuration options that allow Network to calculate the primary.

Process for Unique Checkbox primary objects

To use this configuration to support your business processes, create the field and update your existing objects in your Network instance.

Create a Unique Checkbox primary field - Create a custom field that uses the Unique Checkbox configuration.
Set an active and valid primary on existing records - Set a primary on existing objects in your Network instance. Use the Data Updater or source subscription to update your records.
Edit primary - Users can update the primary field on the record profile. It can also be updated through data loading using the Data Updater or source subscription features.

Create a primary field

For detailed instructions on creating a primary custom field using the Unique Checkbox configuration, see Create primary custom fields.

Setting a primary on existing records

After you create a primary custom field to support your business processes, you'll want to ensure that all existing records in your instance have a primary. With the Unique Checkbox configuration, the primary must be explicitly set because it is managed by users. The primary will not be added or moved unless Network recalculates the primary to avoid duplicates.

To ensure that all existing records in your Network instance have a primary right now, use the Data Updater to set the field. Use reporting to identify the records that do not have an active and valid primary.

To learn more, see Setting an active and valid primary on existing records.

Edit a primary in the Network UI

Any Network user can update the primary address value on a record. Changes are submitted and reviewed by local data stewards.

For details and examples, see Setting a primary in the Network UI.

Resolving duplicate primaries on an object

When primary type fields are configured as Unique Checkbox, 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. To review an example, see Duplicate primaries.

The same behavior occurs on data change requests.

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

If multiple Unique Checkbox 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.

Example - Multiple objects set for a primary field through 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 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.

Example - Multiple set for a primary field through data load

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.

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 master records (Veeva OpenData or third party data) are merged with customer records and a master address is primary, it always wins.

Example 1 - Merging two HCPs with the same addresses set for a primary field

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

Example 2 - Merging two HCPs with different addresses set for a primary field

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.

Example 3 - Merging two HCPs with the same address set for a primary field

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

Example 4 - Merging two HCPs with different addresses set for a primary field

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.