Salesforce Integration Set Up for DSR Automation

The DSR functionality of the integration allows for programmatic DSR fulfillment directly against a Salesforce instance. Property-level settings are available for datapoints that support access and erasure requests to allow for fine-grained redaction customizations.

The integration works to find personal information from contact, lead and individuals objects in Salesforce using a data subject's email or phone number to uniquely identify the user record. When an erasure request is submitted, the contact/lead/individual object will be permanently deleted, unless the corresponding datapoint is configured for redaction. Note that if you use "Person accounts", it is not possible to delete these records.

For standard datapoints in the Salesforce data silo, it's possible to configure specify which fields on the corresponding object should be redacted for access and erasure requests.

For erasure requests, the default is to hard delete the object from Salesforce. If property settings are configured to redact specific fields, the object in Salesforce will be retained and the specific configured fields will be redacted.

When redacting on the standard Individual field in Salesforce, Transcend will set the ShouldForget field to true. This native Salesforce field indicates a right to be forgotten, which indicates the user would like their PII (Personally Identifiable Information) data and any related records deleted. There is no automatic functionality tied to this field, however, Salesforce suggests customers should build automations off of this field using Apex Triggers.

There are a few considerations when deciding whether to redact or delete data when responding to an erasure DSR for Salesforce. Deleting records from Salesforce may reduce compliance risk, but it may interrupt reporting and analytics flows. Additionally, hard deleting records may result in an issue if other integrations re-sync deleted data into Salesforce, in which case redaction would preserve the record and reduce risk of re-syncing data.

For access requests, an object matching the data subject's identifier (email or phone) will be returned to the data subject with all fields from the object. If property settings are configured for redaction, the specified fields on the object will not be returned to the data subject. In other words, using the visibility settings, gives flexibility in determining which fields on the object should be redacted from the final payload returned to the user. For example, there may be a field on the contact object that contains internal notes. It's possible to redact this field from the data returned to a data subject, if this information should be kept internal.

For more information about how to configure redaction for specific fields, see the next section on how to configure Salesforce for DSRs.

For the individuals, lead and contact objects, confirm which types of data actions will be enabled.

Data actions are enabled be default. Specifically review access and erasure actions to ensure configuration is as expected.

Salesforce Datapoints tab
  • For each standard datapoint where redaction of certain fields is desired, select Review XX Properties to configure Property Visibility Settings.
Review Property Settings in Salesforce datapoints
  • Configure ACCESS REQUEST VISIBILITY and ERASURE PROPERTIES TO REDACT as desired.
Configure redaction for Salesforce property-level settings

Navigate back to the DSR Automation tab and toggle the Status setting to Live Mode

Transcend supports running Access and Erasure-based DSR Automation on more than just the Contact, Individual, and Lead standard Salesforce Objects.

In order to enable running DSR Automation on these objects, you will first need to enable the Datapoint Schema Discovery plugin, and then allow the plugin to discover your custom objects.

  1. Once the plugin populates the Manage Datapoints view for the Salesforce data silo in question with all of your custom objects, you should then tag the attributes for all the custom objects you wish to run DSRs, with the Contact/Email or Contact/Phone data categories.
  2. You may then enable the ACCESS and/or ERASURE workflows for the custom object, from the Manage Datapoints view for the silo. a. You can follow the instructions in the Configuring DSR Automation section in order to enable hard-deletion vs. redaction workflows for custom objects too.

That's it! Any new requests (or old ones, re-started) will now also run through those custom objects.

Note: Be aware that we currently only support custom objects that use the Id property as the primary key for the object.