Governance in Hightouch

Overview

Customer Data Platforms (CDPs) are often used by many teams across an organization, including:

Marketers building audiences and launching campaigns
Data teams managing models, permissions, and warehouse access
Administrators overseeing workspace setup, security, and compliance
Regional, brand, or business-unit teams working from shared customer data
Legal, privacy, or operations teams reviewing how data is used

As more teams begin using the same customer data, governance becomes important.

Without clear governance controls, teams can end up with too much access, send data to the wrong destinations, override each other's work, or launch changes without enough review.

Hightouch helps you prevent that by adding governance controls at the activation layer.

Because Hightouch runs directly on top of your warehouse, your warehouse remains the foundation for data access and security. Hightouch inherits the controls already defined there — if a table, column, or dataset is restricted in your warehouse (e.g. via BigQuery IAM policies, Snowflake role grants, Databricks Unity Catalog, or Redshift permissions), Hightouch respects that access automatically. Hightouch then adds controls for how teams work with that data in the product:

Who can access a workspace
What data they can use
What work they can see
What can be sent to downstream tools
Which changes require approval

This guide explains the main governance controls available in Hightouch, why they matter, and when to use them.

How composable governance differs from traditional governance

In traditional customer data platforms, customer data is typically copied into the platform's own infrastructure. That means governance often happens inside a separate system with its own permissions, storage layer, and rules.

Hightouch works differently.

Hightouch connects directly to your existing warehouse and inherits the controls already defined there. If a table, column, or dataset is restricted in your warehouse, Hightouch respects that access. Hightouch then adds additional controls for activation workflows, so teams can use customer data without bypassing the governance your organization already has in place.

In practice, this means governance in Hightouch is composable:

Your warehouse controls the underlying data access
Hightouch controls how teams activate and distribute that data
You can apply only the controls you need based on how your organization works

For most teams, this is easier to manage than creating separate systems or duplicating customer data just to enforce access rules.

What governance helps you manage

Hightouch governance controls help answer a few practical questions:

Who should be able to access this workspace?
What data should each team be allowed to work with?
Which audiences and campaign assets should teams be able to see?
What data should be allowed to leave the platform?
Which changes should require review before going live?

Each control in Hightouch helps with a different part of that process.

1. Control who can access a workspace

Organizations and workspaces

Before configuring workspaces, it helps to understand the two levels of structure in Hightouch: Organizations and Workspaces.

A Hightouch Organization is the parent container representing your company as a whole. It is the top-level entity used for user management, billing, and cross-workspace administration. Within an Organization, you create one or more Workspaces — each a separate environment with its own sources, destinations, models, syncs, and users.

Two pre-built organization-level groups are available by default:

Organization Admin — full access across all workspaces and org-level settings, including managing SSO configuration, billing, creating new workspaces, inviting users, and creating new user groups
Organization Viewer — read-only access across the organization

Workspace-level roles and groups are separate from org-level groups. A user can be an Org Admin without being a Workspace Admin, and vice versa. In practice, Org Admins are typically members of your IT or data platform team, while day-to-day workspace management is delegated to Workspace Admins within each workspace.

SSO and SCIM

For teams managing access at scale, Hightouch supports SAML SSO through identity providers like Okta and Microsoft Entra ID, plus automatic user provisioning via SCIM.

SAML SSO automatically creates Hightouch users on their first login
SCIM synchronizes user account changes from your identity provider to Hightouch automatically — including provisioning, deprovisioning, and group assignments

You configure SSO at the Organization level, then map groups in your identity provider to user groups already defined in Hightouch. When someone joins a team in Okta, they automatically receive the right workspace access and role permissions without manual provisioning.

See:

SSO setup guide

Workspace structure

The next governance decision is whether teams should work in the same workspace or in separate ones.

A workspace is a separate container with its own sources, destinations, models, syncs, and users. Separate workspaces are useful when you need complete isolation, such as:

Regional or data residency requirements
Strict separation between staging and production
Business units that should not share data or configuration

For many organizations, though, separate workspaces are not the best starting point.

If teams share the same underlying customer data, keeping them in one workspace is often easier to manage. It reduces duplicate setup and allows teams to work from the same source of truth while still applying internal governance controls.

Use workspace-level structure when you need hard separation. Otherwise, start with a shared workspace and add more targeted controls inside it.

Create separate workspaces only when required for geo-specific data processing, separate infrastructure, or compliance. For most enterprise customers, a single production workspace is sufficient.

See:

When to use this

Use separate workspaces when you need complete operational or regulatory isolation.

Use a shared workspace when teams should collaborate from the same models and data, but still need scoped access and control.

2. Control what data teams can work with

Once users are in a workspace, the next question is: what data should they actually be able to use?

This is where access controls become important for day-to-day work.

For example:

A regional team may only need access to customers in its market
A brand team may need to work only with its own customer segment
Marketers may need to build audiences without seeing raw PII
Some users may need to review data, while others need to create and launch workflows

Hightouch supports this through user groups and roles, subsets, and data masking.

User groups and roles

Access control in Hightouch is managed at the user group level, not on individual users. A user group is a collection of users who share the same permissions. Each group is assigned a role per workspace, which determines what actions members can take.

There are two types of user groups:

Pre-built groups — Organization Admin and Organization Viewer, available by default
Custom groups — created by org admins to reflect different teams, regions, brands, or any other structure that impacts permissions

A user can belong to multiple groups and inherits the combined permissions of all their group memberships. If a user is in both a Viewer group and an Editor group for the same workspace, they receive the higher level of access — Editor.

Roles define what actions a group can perform within a workspace. Pre-built roles apply across all sources and destinations:

Admin — full grants, typically assigned to data or IT teams
Editor — can create and configure resources, but cannot delete or update existing source and destination configurations
Viewer — read-only access across the workspace
Draft Contributor — can create and propose changes, but cannot publish; all changes go through an approval flow

Custom roles are scoped to specific sources and destinations rather than applying globally. Permissions for dependent resources — models, syncs, and audiences — are inherited from their associated source and destination. Custom role permissions are configured across four dimensions:

General — manage who can create new integrations
Sources — manage rights per source (including schema management, which also governs access to traits, sync templates, and governance features like destination rules and subsets)
Destinations — manage rights per destination
Customer Studio — manage rights per parent model

This means you can create a "Paid Media Marketing" role that has access to Google Ads, Meta, and TikTok destinations but cannot see or touch Salesforce CRM or Braze configurations — enforced at the platform level, not by policy document.

Start with pre-built roles during onboarding. Switch to custom roles to scope access to specific sources and destinations as your usage scales.

See:

Subsets

Subsets limit which records a team can access at the row level.

This is useful when multiple teams work in one workspace but should only be able to use part of the overall customer data, such as:

One region
One brand
One business unit
One consented customer segment

Subsets are enforced at the query level — there is no way to bypass them through the UI or API. Users in the audience builder automatically see only the data their subset allows.

Common subset patterns include consent enforcement (filtering out opted-out customers globally), regional partitions, brand-level segments, and custom suppression lists for legal hold or VIP exclusions.

Subsets are configured under Governance > Subset Categories in Customer Studio.

See:

Subsets

Data masking

Data masking helps teams work with customer data without exposing sensitive values in previews, profile views, or record inspection.

Three masking levels are available:

Approved — data is visible and available for use in syncs and filters
Redacted — data is hidden in the UI (profile details, column suggestions, analytics) but remains accessible for syncs and audience filters
Blocked — data is completely restricted from access and syncs

This is useful when users need to build audiences from behavioral or account data, but should not see raw identifiers or sensitive fields.

See:

Data masking

When to use this

Use these controls when multiple teams share a workspace, but not everyone should have the same level of access to the same data.

3. Control which campaign assets teams can see

The previous section covered who can access the platform and what underlying data they can query. This section is about something different: which audiences, syncs, and campaign assets different teams can see once they're inside the workspace.

Even if two teams have identical data access, they may have no reason to see each other's audiences, syncs, or journeys. Without that separation, large workspaces become noisy, harder to navigate, and easier to change by mistake.

Spaces

This is where Spaces help.

Spaces let you partition a single workspace into isolated sub-workspaces for different regions, brands, teams, or business units. Within a Space, teams work from the same underlying models, sources, and destinations — but their audiences and syncs are scoped to that Space and are not visible to other teams.

Key behaviors:

Models, sources, destinations, and schema are shared across all Spaces in a workspace
Audiences and syncs are scoped to a specific Space
Only users with explicit access to a Space can create, view, or edit its resources
Workspace admins retain cross-Space visibility for governance and troubleshooting
Access is managed via user groups, not individual users

In practical terms, Spaces help answer questions like:

Which audiences should this team see?
Which syncs belong to this region?
How do we keep one team from accidentally editing another team's work?

When enabled, Spaces can be accessed and configured under Settings → Workspaces → Spaces.

Spaces is currently in early access and must be enabled for your workspace by your Hightouch team. Contact your Hightouch representative to request access.

See:

Spaces

When to use this

Use Spaces when teams should share the same workspace and data foundation, but should not all see the same campaign assets or operational work.

4. Control what data can leave Hightouch

One of the most important governance decisions is what happens when customer data is sent to downstream tools or destinations.

Even if the right team built the right audience, you may still need to control:

Which records can be synced to a destination
Whether consent rules are enforced
Which fields are allowed to be mapped
Whether syncs follow an approved setup pattern

Hightouch supports this through Destination Rules, Data Masking, Audience Templates, and Sync Templates.

Destination Rules

Destination Rules automatically filter which records are eligible to sync to a specific destination.

They are evaluated at sync time — they do not affect the underlying audience definition. Think of them as a channel-specific filter that Hightouch applies automatically every time an audience syncs to a given destination.

They are especially useful for enforcing requirements like:

Email consent
SMS consent
Advertising consent
Regional policy restrictions
Minimum audience thresholds
Frequency capping

This helps move consent enforcement out of individual campaign setup and into a reusable governance control that applies regardless of who built the audience or which Space it belongs to.

Destination Rules are configured under Governance > Destination Rules in Customer Studio.

See:

Destination Rules

Data Masking

Data Masking can also be used at the destination layer to ensure that raw sensitive values — such as email addresses or phone numbers — are not mapped to destinations that only need hashed identifiers or anonymized fields.

See:

Data masking

Audience Templates

Audience Templates let admins define reusable audience structures that users can quickly adapt with minimal changes.

Admins set up an audience as usual but leave certain fields blank — those become the fields users fill in when creating an audience from the template. This ensures that baseline segmentation logic, suppression rules, and consent filters are baked into every audience from the start. Marketers can customize within the template's parameters but cannot bypass the foundational logic.

You can also mandate that all new audiences must start from an approved template, ensuring governance guardrails are always in place.

Audience Templates are configured under Templates > Audience Templates in Customer Studio.

See:

Audience Templates

Sync Templates

Sync Templates give teams an approved starting point for destination configuration.

Instead of setting up every sync from scratch, admins can define approved mappings, modes, and field-level permissions ahead of time. For specific fields, admins can use the editable toggle to allow users to customize only those fields when creating a sync from a template.

You can also enforce the use of sync templates entirely by enabling the Require sync templates toggle in Settings.

This helps teams move faster while reducing setup mistakes and configuration drift.

Sync Templates are configured under Templates > Sync Templates in Customer Studio.

See:

Sync Templates

When to use this

Use destination-level controls when different downstream tools have different requirements, or when your team wants to enforce safe and repeatable activation patterns.

5. Organize and navigate workspace resources

As workspaces grow, teams need ways to keep resources organized and easy to find. Hightouch provides three tools for this: Folders, Labels, and Filters.

Folders

Folders let you organize resources like syncs, models, and audiences into a shared hierarchy. You can group resources in a strict hierarchy or organize by team or department. Folder hierarchy is shared across resource types — moving a sync also moves its associated model to the same folder.

Only workspace admins can modify the folder structure. Other roles can add or remove resources from existing folders.

Labels

Labels are key/value pairs that let you tag resources across multiple dimensions that don't fit into a folder structure. For example:

Track campaign type: type:email, type:sms, type:push
Track brand or region: brand:brand-a, region:eu

Multiple labels can be applied to a single resource. You can then filter by label combinations in the sidebar.

Filters

Filters let you narrow the resource list by attributes like sync progress, destination, source, health status, and more. Once you've set up a useful filter combination, you can save it for future use.

See:

Folders and labels

When to use this

Use these tools in any workspace with multiple teams or a large number of resources. They don't enforce access — they improve discoverability and reduce noise.

6. Control which changes require review

Some changes are low risk. Others should not go live without review.

For example:

Launching a new audience to a paid media platform
Changing sync mappings for a production destination
Updating logic that affects a large customer segment
Allowing less technical users to propose changes without publishing directly

Hightouch supports this through Approval Flows, and in some cases through Environments for staging and production workflows.

Approval Flows

Approval Flows let designated users create or edit resources in draft mode, then require review before those changes go live.

To set this up:

Enable the Require Approvals toggle in Settings > Workspace

Assign the Workspace Draft Contributor role to users who should go through the approval process
By default, all roles except Workspace Draft Contributor and Workspace Viewer can grant approval — if you need to grant approval permissions to other roles, build a custom role

Approval Flows pair well with Audience Templates and Sync Templates. When both are in place, admins can require that all new audiences start from an approved template — ensuring that baseline segmentation logic, suppression rules, and consent filters are baked in. Marketers can customize within the template's parameters but cannot bypass the foundational logic.

This is useful when you want marketers or operators to move quickly, but still want an admin, data team, or compliance owner to review higher-impact changes first.

See:

Approval flows

Environments

Environments help teams separate testing from production and move changes more intentionally between them. Each workspace acts as a separate environment. You can link workspaces and deploy models and syncs from one environment to another without recreating them from scratch.

Before a deployment executes, Hightouch validates that all underlying resources (sources, destinations, models) match their production counterparts — preventing mismatches that could cause data integrity issues.

See:

Environments

Audit visibility

Governance also depends on being able to understand what changed, when, and by whom.

Audit logs are available under Settings > Audit log and track up to 90 days of in-app activity. Each log entry records the user, action, resource, and a before/after JSON diff. For longer retention or custom dashboarding, audit data can also be written back to your warehouse via Warehouse Sync Logs.