OneTrust Snowflake Native App

The OneTrust Snowflake Native App streams consent and preference data from OneTrust into your Snowflake warehouse. Once it's connected to your schema, Hightouch can enforce that consent with subsets, destination rules, and sync behavior.

Overview

If you use OneTrust Universal Consent and Preference Management (UCPM) to manage customer consent and communication preferences, the OneTrust Snowflake Native App syncs that data into your Snowflake warehouse in near real time. Every opt-in, opt-out, and preference change stays current, and Snowflake's own governance controls mask rows and columns so each role only sees what it's permissioned for.

Once consent lives in your warehouse, Hightouch can reference it to:

• Filter audiences with subsets.
• Block unconsented records with destination rules.
• Remove records from destinations when a customer revokes consent.

Together, these ensure destinations only receive data from customers who have given the appropriate consent.

Connect OneTrust consent data

Bring OneTrust data into Hightouch by connecting it as a source and adding it to your schema.

1. Install the OneTrust Snowflake Native App. Follow OneTrust's setup guide to stream consent and preference updates into a table in your Snowflake warehouse.

2. Connect Snowflake as a source. Follow the Snowflake source setup so Hightouch can read the OneTrust data.

3. Create a parent model. Go to Customer Studio > Schema, click Create parent model, and select your primary user table (for example, users). See Define your schema.

4. Add your consent table as a related model. Join it to the parent model and choose a relationship type:

   • Use 1:1 if you have a single consent purpose.
   • Use 1:many if you have multiple consent purposes, since OneTrust stores each type in a separate row.

   You may want to transform the consent table or expose a view first, depending on your OneTrust setup.

5. Select the consent columns to expose, such as email_opt_in, sms_opt_in, or ad_sharing_opt_in.

These fields are then available throughout Hightouch to filter audiences, enforce destination rules, and drive sync behavior based on consent.

Enforce consent in Hightouch

Filter audiences by consent with subsets

Use subsets to define reusable, consent-based filters. Because subsets apply as base filters across audiences and syncs, they keep unconsented customers out of every audience built on that parent model.

Hightouch provides a built-in Consent management subset category with default consent subsets, so you can grant access to a subset like Email without building it from scratch. You can also create your own. For example, define a subset that includes only records where email_opt_in = true. Once created, a subset can be:

• Applied to multiple audiences for consistent filtering across use cases.
• Set as required for a team, so those marketers can't build audiences without selecting a consent value.
• Restricted to approved values, so users can only select the options you allow.

Suppress unconsented records with destination rules

Use destination rules to block records from syncing to a destination when they don't meet consent criteria. For example, block records where sms_opt_in != true from syncing to your SMS tool. This acts as a final safeguard against delivering unconsented data.

Remove records when consent is revoked

When a customer revokes consent, Hightouch can remove them from downstream tools — but only if the model is filtered by consent and the sync is configured to support removals.

Recurring syncs. On the next scheduled run, Hightouch removes any records that no longer match the model's filter. This requires:

• A consent-based filter on the model or audience (for example, email_opt_in = TRUE).
• A sync mode that supports removals.
• Record removal enabled in the sync configuration.

Triggered syncs. If your model and destination support real-time updates (for example, through change data capture or an event stream), Hightouch can configure the sync as triggered. Enable record removal on the sync so a customer is dropped from the destination as soon as their consent changes, rather than on the next scheduled run.

Model consent and preference data

The OneTrust Snowflake Native App can sync far more than binary opt-ins. When you define your schema, consider exposing:

• Channel-specific consent — email_opt_in, sms_opt_in, push_opt_in, so you can enforce channel-level rules in subsets and destination rules.
• Frequency preferences — for example, email_frequency = weekly, to suppress over-messaging by filtering for lower-frequency segments.
• Content or category preferences — for example, category_preference = mens_clothing, to target customers by stated interest.
• Data-sharing consent — for example, ad_sharing_platform_opt_in = true, so records only reach third-party platforms like Meta or Google when consent exists.

Next steps

• Subsets to scope audiences by consent.
• Destination rules to block unconsented records at the destination.
• Consent Manager for Events and OneTrust for Events for event-based consent collection.
• OneTrust Universal Consent and Preferences Management for OneTrust's own documentation.