Unsubscribing from third-party records


Administrators can unsubscribe from records from third-party master feeds and then anonymize the records in Network. This enhancement supports the GDPR requirements for allowing HCPs to request that their data is removed and also to remove data that is no longer needed; for example, to delete HCP records that sales reps no longer visit.

Unsubscribe process

When HCPs ask for their data to be deleted from your database, you must notify the third-party data provider and unsubscribe from the records so they are no longer included in the data feed you receive.

Follow the steps below to unsubscribe from the records from the third-party data provider.

Step 1 - Contact the third-party provider

When HCPs have requested removal of their data, advise the third-party provider. Agree on the field and value that will be used in the next delta data feed to indicate that the record is now unsubscribed.

Step 2 - Create Network expression rules

In the source subscription for the third-party data provider, create a NEX rule using the UNSUBSCRIBE() and RESUBSCRIBE() functions. These are new functions to support this feature. The RESUBSCRIBE function supports adding an unsubscribed record back into your Network instance.

   "IF(status == 'DELETED', UNSUBSCRIBE())",
   "IF(status == 'ACTIVE', RESUBSCRIBE())",

Note: The status field and the DELETED and ACTIVE values are examples. Replace them with the field and value that the third-party data provider uses to indicate that the records are unsubscribed or resubscribed.

The File Preparation and Transformation rule points support these functions.

The next time the source subscription runs and the UNSUBSCRIBE() function is called, the record state in Network is set to DELETED.

Step 3 - Export deleted records

Allow time for the deleted record to be pushed to your downstream systems (for example, Veeva CRM) through your scheduled target subscriptions.

Step 4 - Anonymize personal data in deleted records

After the deleted record is pushed to all downstream systems (for example, two weeks later), you can choose to anonymize the personal data stored in the unsubscribed records. When deleted HCP records are anonymized, all of the personal data is masked or blanked out and access to the record is further restricted in the Network instance. If records are exported to downstream systems, only record information and data that is not personally identifiable (created date, last modified date, VID, record state, and so on) can be viewed.

To anonymize records:

  1. Use Network Reporting to identify any third-party records that were unsubscribed and deleted.

    Navigate to Reports > SQL Query Editor and type the following SQL query:

    select vid__v from HCP
    where record_owner_type__v = 'TTP'
    and record_state__v = 'DELETED'

    To show records with a DELETED record state, ensure that the Include only VALID and UNDER_REVIEW records in results checkbox is not selected.

  2. Create a .csv file to include the Network entity ID of the affected records; the records from the report results.
  3. Run the Anonymize Deleted HCP Records data maintenance job to anonymize the personal data in the records.

The anonymized records are no longer available in Network.

NEX functions

The UNSUBSCRIBE () function can only be called for third-party managed HCO and HCP records. It does not process locally managed or Veeva OpenData-managed records.


When the NEX functions for UNSUBSCRIBE or RESUBSCRIBE are called, the following behavior occurs on records managed by a third-party provider:

  • The record state is set to DELETED.
  • The record state of all related sub-objects and relationship objects are set to DELETED.
  • All custom keys associated with the root object (HCO, HCP) remain active. (This is for matching purposes in case you need to resubscribe to the record again).
  • The record status of all associated sub-objects is set to inactive.
  • All parent HCO relationships that point to a deleted HCO are deleted and inactivated.
  • Any custom keys on the parent HCO relationship that point to a deleted HCO are inactivated.
  • A new valid third-party record is created. The old third-party record that was previously unsubscribed remains DELETED.
  • The new record contains a new Network entity ID (VID) and the original custom keys.
  • Custom keys of the unsubscribed record (old record) are inactivated

Supported records

The UNSUBSCRIBE() NEX function can update the following record states to DELETED:

  • Valid
  • Invalid

The following record states are not supported:

  • Under_review
  • Merged_into

Options for HCP requests to third-party data providers

HCPs could request removal of their data from the data provider, but give consent for you to process their personal data. In this case, data providers typically inform their customers that HCPs have opted out of their database so the record will no longer be included in your data feed. This means that you will no longer receive updates to the data and your sales reps can no longer submit change requests for the record.

In this situation, there are two potential options you can consider:

Option 1 - Allow the third-party managed record to remain active

You might decide to allow the record to remain active in your Network instance. The third-party data provider removes the HCP from the data feed, so you no longer receive updates and any DCRs sent for that record are rejected by the third-party data provider.

Option 2 - Create a locally managed record

Because the current record will no longer be updated, you can alternatively create a new locally managed record for the HCP. This ensures that any changes requested to the data are processed by local data stewards. To avoid duplicate records in your Network instance, ask the third-party provider to update the record to a state that triggers the NEX function during the next data feed so the record state in your Network instance is set to DELETED. After the updates are exported to your downstream systems, run the data maintenance job to anonymize the personal data in the deleted record.

Resubscribing to records

You can resubscribe to a third-party record after it's been deleted and the personal data is anonymized in Network. For example, HCPs might give consent to process their data again, or you might find that a record has been unsubscribed to by mistake and your sales reps need to visit that HCP again.

Follow the steps below to resubscribe to the third-party record.

Step 1 - Contact the third-party data provider

If a sales rep obtains consent from an HCP to process their data again, the sales rep can create an add request in Network which will be routed to the third-party data provider. Based on the incoming add request, the third-party data provider can include the record in the data feed again and change the record state so it will trigger the RESUBSCRIBE() NEX function.

Alternatively, if the unsubscribe was a mistake, you can contact the third-party data provider directly and request that the record is set to a state that will trigger the RESUBSCRIBE() NEX function.

Step 2 - Run the source subscription

The next time the delta subscription runs, the NEX rule is triggered and calls the RESUBSCRIBE() function.

   "IF(status == 'DELETED', UNSUBSCRIBE())",
   "IF(status == 'ACTIVE', RESUBSCRIBE())",

Note: The status field and the DELETED and ACTIVE values are examples. Replace them with the field and value that the third-party data provider uses to indicate that the records are unsubscribed or active.

When the source subscription completes, it has the following impact:

  • A new record is created in Network for the HCP.

    The data in the new record is based on information from the data feed only. When a record is resubscribed, the information (sub-objects, source keys, and so on) from the old record is not moved to the new record.

  • The new record contains a new Network Entity ID (VID) and the custom key from the old record (that remained active when the record was unsubscribed).
  • The old record for the HCP remains DELETED (original VID).
  • The custom key on the old record is set to inactive.

Users can view and update the new record; data change requests will be routed to the third-party data stewards.