New products. New navigation bar. Read up here!

Preflight Checks & Identity Enrichment

Before processing begins for a DSR, the request is validated by a series of preflight jobs to ensure that it is legitimate and well-equipped to be fulfilled. During this step Transcend runs a set of customizable checks which include the following, and can be edited in the Admin Dashboard:

  • Verification of other unverified identifiers, including but not limited to phone number, email, and government ID.
  • Manually notifying a human to confirm if a request should be processed.
  • Obtaining all identifiers related to a request such as a User ID (identity enrichment).
  • Performing Anti-fraud check.
  • Checking if the requestor is on an existing legal hold that prevents the request from being processed.

A few things to know about preflight checks:

  • Preflight checks typically require a single Input Identifier, used as the condition to trigger the preflight check.
  • Some preflight checks can return multiple Output Identifiers. Think of this as the other identifiers (e.g. user_id, phone) that were found keyed to the Input Identifier.
  • Preflight checks are configurable to run on any combination of Data Actions and Data Subjects.
  • Preflight checks can define dependencies to each other, to define the order in which they will resolve.
  • All identifiers need to verified before the request continues to the "Compiling" phase. Identifiers can be verified by preflight checks, or if you decide that you do not want to verify an identifier, the Auto Approve preflight check can be used.

Preflight checks can be created under the DSR Automation -> Identifiers page of the Admin Dashboard. Click the "+" button under the Preflight & Identity Enrichment section to create one of the following types of preflight checks:

  1. Email verification (magic link)
  2. Phone number verification via SMS (magic link)
  3. Post to a Server (Webhook)
  4. Notify a Person
  5. Region Matcher
  6. RegExp Match
  7. Auto Approve
  8. Database Enricher
  9. Looker Enricher
  10. Legal Hold Check
  11. Wait Period
  12. Government ID verification via Stripe Identity (magic link)

DSR workflows submitted through the Privacy Center configured with email verification by default. This is a separate process from the Email Verification preflight check described below, and you can read more about the Privacy Center email verification process here. When using this default Privacy Center email verification DSR only show up in the Incoming Requests view after the email is already pre-verified.

The email verification preflight step is a configuration setting that is run whenever a request is submitted with unverified email addresses. There are 3 ways to submit a request with unverified email addresses:

  1. When Manually submit a Data Subject Request through the Admin Dashboard and selecting "Yes, ask the user to verify the request".

  1. When submitting requests through Transcend's DSR API with 2FA Email Approval enabled.

  2. When using account login flows on the Privacy Center via JWT or OAuth while also indicating in the authentication payload that the user's email is not verified.

The "Transcend Email Verification" preflight step has the following configuration settings that are commonly customized:

  • Verification Template: Provide the template that should be sent to the identifier that is being verified. This same template will be sent for all verification attempts when the verification is set up as a drip campaign.
  • Expiration Duration: The amount of time (in hours) until the identifier will be considered not verified. After this verification window is hit, the default behavior is for the request to enter the "Failed Verification" status with no further communications sent to the data subject. Read the descriptions for the settings below to understand alternative workflows that can be configured.
  • Request Verification Failed Template: Provide an email template that should be sent to the primary email for a request after the "Expiration Duration" window passes. When a template is specified, the request will enter a "Verification Failed" status, and the request will have to be re-submitted by the data subject, or restarted by an admin. It is common to provide an email template that instructs the data subject that their request was canceled, with additional instructions explaining how to re-submit the request.

The default configuration is to send the Verification Template one time, and then silently expire the request after 24 hours, changing the request status to "Failed Verification".

By specifying the Request Verification Failed Template, you can notify the user that their request was canceled when the verification fails.

You can additionally configure the "Transcend Email Verification" preflight step to send a "Drip Campaign" where the email specified by Verification Template is sent multiple times. In order to set up the "Drip Campaign", you will want to update the Expiration Duration to be longer enough to run the Drip Campaign, and then set the following settings to define the length of time between consecutive emails being sent.

  • Drip Campaign - Reminder Template 1 Duration: The amount of time (in hours) that should wait between first email and second email. Note that in order for this drip campaign email to send, the "Expiration Duration" settings must be greater than this duration.
  • Drip Campaign - Reminder Template 2 Duration — The amount of time (in hours) that should wait between second email and third email. Note that in order for this drip campaign email to send, the "Expiration Duration" settings must be greater than the sum of this duration and "Drip Campaign - Reminder Template 1 Duration".
  • Drip Campaign - Reminder Template 3 Duration: The amount of time (in hours) that should wait between third email and fourth email. Note that in order for this drip campaign email to send, the "Expiration Duration" settings must be greater than the sum of this duration, "Drip Campaign - Reminder Template 1 Duration" and "Drip Campaign - Reminder Template 2 Duration".

Below is an example where:

  • Email Verification template is sent for the first time immediately when request is received
  • A second Email Verification template is sent 24 hours later after the request is received but not verified
  • A third Email Verification template is sent 24 hours after the second email, 48 hours after the request was submitted.
  • A fourth Email Verification template is sent 24 hours after the third email, 72 hours after the request was submitted.
  • The Request Canceled template is sent 95 hours after the request is made and the Expiration Duration window is passed.

Lastly, the following settings can be customized to only run the "Transcend Email Verification" preflight check for specific workflows:

  • Actions: Only run this preflight check for specific data actions types (e.g. Access, Erasure, etc.).
  • Preflight Dependency: Run this preflight check only after other preflight checks have been resolved.
  • Data Subjects: Which data subject types should trigger this preflight check. When not provided, this preflight step is run for all data subjects.

If you need a method to identify a data subject by a phone number, the Twilio SMS preflight check may be a good choice. This preflight check works by leveraging your Twilio account to send a 2FA text code to a mobile cell. The data subject will click a link that confirms their identity and redirects them back to the privacy center.

Step 1) Connect the Twilio Integration

To set it up, first set up a new integration with Twilio.

Step 2) Configure an Email Template

After that, create a new template inside Email Templates with the Internal Title equal to 'Phone number verification' if there is no template with that name.

Add a 'Message Subject' and a 'Message Template'. The 'Message Template' can include {{{ verifyUrl }}}, that will be filled with the verification URL that the user will click to verify their phone number, and {{{ noVerifyUrl }}} to reject the verification request. {{{ verifyUrl }}} is a variable that will be filled by our platform with the verification URL that the user will click to verify their phone number. {{{ noVerifyUrl }}} is a variable that will be filled by our platform with the URL that the user will click to reject the verification request. One example of a message that you can use is:

Hi there! You recently made a request of type {{type}}. Please verify your phone number by clicking this link: {{{ verifyUrl }}}. Not you? Click this link to block this request: {{{ noVerifyUrl }}}.

Step 3) Configure the phone identifier to appear in the Privacy Center

Next you'll want to make sure you have a phone identifier created. If that is not set up yet, go to the Identifiers and create a new one. You'll want to enable that identifier to be visible on the Privacy Center by setting the Prviacy Center Visibility setting.

This will expose the identifiers in the Privacy Center confirmation form:

Step 4) Create the preflight check

Next, go ahead and create a new preflight check with type "Twilio Phone Number Verification".

The "Twilio Phone Number Verification" preflight step has the following configuration settings that are commonly customized:

  • Twilio Integration: The Twilio integration to use to send texts, set up previously in step 1
  • Verification Template: Provide the template that should be sent to the identifier that is being verified. This same template will be sent for all verification attempts when the verification is set up as a drip campaign. This was set up in step 2.
  • Expiration Duration: The amount of time (in hours) until the identifier will be considered not verified. After this verification window is hit, the default behavior is for the request to throw an error and generate an action item.
  • Request Verification Failed Template: Provide an email template that should be sent to the primary email for a request after the "Expiration Duration" window passes. When a template is specified, the request will enter a "Verification Failed" status, and the request will have to be re-submitted by the data subject, or restarted by an admin. It is common to provide an email template that instructs the data subject that their request was canceled, with additional instructions explaining how to re-submit the request.
  • Request Continuation Template: Provide an email template that should be sent to the primary email for a request after the "Expiration Duration" window passes. When a template is specified, the unverified identifier will be removed from the request, and the request will continue being processed for all other verified identifiers. Note: This cannot be set in combination with the "Request Verification Failed Template". If both are set, the "Request Verification Failed Template" is used and the request enters a "Failed Verification" state.
  • Twilio Phone Number *: For each region that data subjects may be, add a phone number for that region. You can find these numbers on Twilio's console. The number should have the ability of sending SMS messages. For each region that you want to support, add a phone number with the specified region. For example, if you want to add support for the US, add a phone number with the number +1XXXXXXXXXX. If you want to add support for the UK, add a phone number with the number +44XXXXXXXXXX, and so on.

You can additionally configure the "Twilio Phone Number Verification" preflight step to send a "Drip Campaign" where the text message specified by Verification Template is sent multiple times. In order to set up the "Drip Campaign", you will want to update the Expiration Duration to be longer enough to run the Drip Campaign, and then set the following settings to define the length of time between consecutive texts being sent.

  • Drip Campaign - Reminder Template 1 Duration: The amount of time (in hours) that should wait between first and second texts. Note that in order for this drip campaign email to send, the "Expiration Duration" settings must be greater than this duration.
  • Drip Campaign - Reminder Template 2 Duration — The amount of time (in hours) that should wait between second and third texts. Note that in order for this drip campaign email to send, the "Expiration Duration" settings must be greater than the sum of this duration and "Drip Campaign - Reminder Template 1 Duration".
  • Drip Campaign - Reminder Template 3 Duration: The amount of time (in hours) that should wait between third and fourth texts. Note that in order for this drip campaign email to send, the "Expiration Duration" settings must be greater than the sum of this duration, "Drip Campaign - Reminder Template 1 Duration" and "Drip Campaign - Reminder Template 2 Duration".

When the preflight check is set up correctly you will see it under the "Details" tab of the request:

When the preflight check is run, a text will be sent to the data subject's phone number. The data subject will click on the link and the phone number will be verified, completing the phone number verification.

If you need to contact a web service in order to resolve an identifier (username, internal ID, etc.), Transcend supports Webhooks in order to collect that additional information.

Webhooks can also be used to automatically cancel incoming DSR Automation based on your business or legal needs, or simply put them on hold until further resolution.

The "Post to a Server" preflight check can be configured by following the steps described here.

If no automated service is available for an identifier to be resolved, the "Notify a Person" allows you to contact someone and ask for the username, ID, or any identifier corresponding to the existing identifiers associated with the request. You can configure the notification to run conditionally only if a user specifies another type of identifier, the input identifier.

Under the DSR Automation section, Identifiers, make sure each of the identifiers you plan to return is listed. If not, use the + button to define new identifiers.

Note that the identifiers' name that you configure here have to match with the "name" of the identifier used in your payload.

  1. Go to DSR Automation -> Identifiers.
  2. Add a new preflight check by clicking the blue + button in the top-right-hand corner of the "Preflight & Identity Enrichment" section.

  1. Select the Notify a Person preflight check and enter all the necessary information, which includes:
  • Title: Title of preflight check.
  • Description: Description of preflight check.
  • User to Notify: Transcend user or email of the person to contact for this preflight check.
  • Input Identifier: Initial identifier that the preflight check will be triggered by. A DSR will only use this preflight check if any of its identifiers is the same type as the input identifier specified here. Select Core Identifier if you want to run this step for every request.
  • Output Identifier: The output identifiers that can be manually entered.
  • Actions: Which data actions types (Access, Erasure, etc.) that this preflight check should be triggered for.
  • Data Subjects: Which data subject types that this preflight check should be triggered for. When not provided, this preflight step is run for all data subjects.
  • Preflight Dependency: Delay running this preflight check until other preflight checks are resolved first.

  1. Click Create Preflight check.

  2. Requests in need of enrichment will lead to an action item being created in your Transcend dashboard, assigned to the user(s) specified in the preflight check configuration. If needed, you can assign a Transcend user or a Team to the DSR Preflight Check Manual Action Required action item.

  1. You can subscribe to alerts for Identity Enrichment by clicking Manage Subscriptions in the top-right corner, search for the DSR Preflight Check Manual Action Required notification type, and selecting the way you want to be notified (Email, Slack, etc.).

  2. Preflight check status status can be found in the Details tab of a pending request tab.

Click on the blue pencil icon next to the preflight check to provide the required information.

The Region Matcher can be set to detect any number of countries or states originations for the subject request, and automatically set the request to a specific state, such as cancelling it or placing it on hold.

This is commonly used to reject certain DSRs in certain jurisdictions and used in tandem with region selection that can be configured for each request type from the "Request Settings" section of the dashboard.

The below example shows a preflight check configured to automatically reject requests coming from US states that don't have privacy laws, and delay email for 24 hours after request is received.

Similarly to the Region Matcher, RegExp Match will run the provided Regular Expression on the Input Identifier, and change the status of the request when a match is found.

The screenshot below illustrates a preflight check set up to automatically reject requests for which the input identifier (email) end with "@acme.com".

Identifiers collected through the Privacy Center need to be verified before the request is continued. In some situations, you may want to process the request without verifying the identifier. You can do this using the Auto Approve preflight check.

The screenshot below illustrates an Auto Approve preflight check set to accept Erasure requests based on including a custom identifier of type MAC Address. You might want to do so if you are not be able to verify a mac address belongs to one person, but you want to allow users to request deleting from that mac address because its tied to personal data.

You might also want to auto-approve an identifier of type name, if you are not actually leveraging it to look up data, but rather use it to communicate to your user and/or cross-referencing in the bulk respond UI.

Enrichment can be performed by querying one of your databases via the Database Enricher. For example, you could write an SQL query that maps an email address to a set of user_ids and phones that you have related to that email address. Full configuration steps can be found here.

The Looker enricher allows for a no-code enrichment of identifiers through your Looker Integration.

Please note that if possible, database Integration or a Webhook Integration are still the preferred method of integration, as it is preferable to enrich from a live production database. A data warehouse is a replica of the production database, and as such it is possible to see a delay in data arrival during the time when data is copied over from the production database.

Note that you can declare a dependency on a Wait Period enricher in order to delay processing and give time to ensure ETL is run before enriching the request.

Full configuration steps for the Looker Enricher can be found here.

If you maintain a list of users that shouldn't be automatically processed, for legal, business reasons or otherwise, you can set the Legal Hold Check preflight check to compare inbound identifiers against that list and modify its status in case of a match.

You can choose which new status should be set to the matching request by setting the Request Status Transition field, and select an email template to send to the data subject, with the Email Template field.

To define your Legal Hold list:

  1. Go to the DSR Automation -> Legal Holds section of your DSR Automation dashboard.
  2. From there, you can add identifiers to your list manually, or upload larger lists using the Import button.
  3. The input list for imports should be a csv file with identifier and value as column headers, and values:
  • identifier: identifier name. For example: email
  • value: actual identifier value. For example: mike@transcend.io You can add any and/or multiple other types of identifiers using this method.
  1. Create a preflight check for each identifier type that you want to check from the list of legal holds. You can configure which data subject workflows or data actions the legal hold would run on.

The Wait Period preflight check can be used to force a delay between steps of your DSR workflow. Provide the Identifier that should trigger the wait period, as well as the Expiration Duration.

Keep in mind that preflight checks can include Dependencies to one another and thus be run in chosen sequential order, if you need to delay processing of a preflight check while a database process takes place, for example.

The Government ID verification preflight check can be used to verify data subjects by having them verify with their government ID using Stripe Identity.

How it works: To support this form of verification, you will need to add a preflight check. The preflight check will send a verification link from Stripe Identity to the data subject's email. The integration will then check the status of the verification once every 12 hours for completion or cancellation.

To set this up, set up a new integration with Stripe.

Next, edit the default email template as needed inside Email Templates with the title "Government ID verification" or create a new template.

Then, set up the preflight check in DSR Automation -> Identifiers page by creating a new preflight check with type "Stripe Identity Government ID Verification". After filling out the fields as needed including adding the Stripe integration and the email template in the form, hit "Create Preflight Check". After that, you will have the proper setup for running new requests with government ID verification.

The preflight check will run when a request is sent and send a verification link to the user's email. The status of the request will look like the following:

On the customer side, the user will be emailed a link to verify their government ID with the template specified.

If the user clicks the link and completes verification successfully, the status of the request will look like the following: