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 |
Unmerging records
When records are unmerged from each other, any fields that were set as primary on the original records are recovered.