> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hightouch.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Governance best practices

> Learn when to use governance controls like roles, subsets, Spaces, destination rules, approval flows, and environments to manage access, collaboration, and activation safely.

## 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](https://docs.hightouch.com/sources/snowflake-rbac), 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.

> [!NOTE]
>
> [**Explore the interactive architecture diagram →**](https://architecture.hightouch.com/?from=docs\&product=governance\&utm_source=hightouch-docs\&utm_medium=referral\&utm_campaign=architecture-explorer\&utm_content=governance)
>
> See how governance controls fit into the Hightouch architecture.

## 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**](https://docs.hightouch.com/workspace-management/overview.md#organizations) and [**Workspaces**](https://docs.hightouch.com/workspace-management/overview.md#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.

![SSO setup](https://mintcdn.com/hightouch-3c037897/L_vQfA0JQEpeGUUo/images/workspace-management/governance/gov-sso.png?fit=max\&auto=format\&n=L_vQfA0JQEpeGUUo\&q=85\&s=7848414d09289bfd08dd13259414d747)

See:

* [SSO and SCIM](https://docs.hightouch.com/workspace-management/sso.md)

### 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.

> [!TIP]
>
> 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:

* [Workspaces](https://docs.hightouch.com/workspace-management/workspaces.md) — includes a [side-by-side comparison](https://docs.hightouch.com/workspace-management/workspaces.md#do-you-need-another-workspace) of workspaces vs. environments
* [Core concepts](https://docs.hightouch.com/workspace-management/overview.md)
* [Environments](https://docs.hightouch.com/workspace-management/environments.md)

### 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 editor** — can create and propose changes, but cannot publish; all changes go through an approval flow

  ![Default roles in Hightouch](https://mintcdn.com/hightouch-3c037897/L_vQfA0JQEpeGUUo/images/workspace-management/governance/gov-default-roles.png?fit=max\&auto=format\&n=L_vQfA0JQEpeGUUo\&q=85\&s=c28bb4cc8048153be45de4ee0d2e0c56)

**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. The custom role builder groups permissions by resource and product. For example, you can:

* Control who can create new sources and destinations
* Grant rights per source (including [schema management](https://docs.hightouch.com/customer-studio/schema.md), which also governs access to traits, sync templates, and governance features like destination rules and subsets)
* Grant rights per destination
* Grant rights per parent model and general model on the **Models** tab
* Control access to Agents, Ad Studio, and Lifecycle Studio
* Control creation and per-resource rights for event sources, destinations, contracts, and functions

Workspaces with products such as AI Decisioning, Native Delivery, or Spaces show additional tabs for those products. See [Roles](https://docs.hightouch.com/workspace-management/roles.md#custom-role-grant-reference) for every grant.

![The Workspaces tab of a group in Organization settings, with the Role dropdown open](https://mintcdn.com/hightouch-3c037897/L_vQfA0JQEpeGUUo/images/workspace-management/permissions/group-workspaces.png?fit=max\&auto=format\&n=L_vQfA0JQEpeGUUo\&q=85\&s=9927f52ef1a1f0cf03c86612f79e6163)

![New group in Hightouch](https://mintcdn.com/hightouch-3c037897/L_vQfA0JQEpeGUUo/images/workspace-management/governance/gov-new-group.png?fit=max\&auto=format\&n=L_vQfA0JQEpeGUUo\&q=85\&s=fefa9514132c217be0f23293284c5aaa)

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:

* [User groups](https://docs.hightouch.com/workspace-management/user-management.md)
* [Roles](https://docs.hightouch.com/workspace-management/roles.md)

### 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](https://docs.hightouch.com/customer-studio/subsets.md)

### 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](https://docs.hightouch.com/customer-studio/data-masking.md)

### 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**.

> [!NOTE]
>
> Spaces must be enabled by Hightouch. [Contact us](#pylon-chat) to turn it on.

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](https://docs.hightouch.com/destinations/overview.md).

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](https://docs.hightouch.com/customer-studio/destination-rules.md)

### 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](https://docs.hightouch.com/customer-studio/data-masking.md)

### 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](https://docs.hightouch.com/customer-studio/templates.md#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](https://docs.hightouch.com/customer-studio/templates.md#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](https://docs.hightouch.com/workspace-management/folders-filters.md)

### 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:

1. In **Settings > Workspace**, under **Require approvals**, turn on **Syncs & Models**

   ![Require approvals](https://mintcdn.com/hightouch-3c037897/L_vQfA0JQEpeGUUo/images/workspace-management/governance/gov-require-approvals.png?fit=max\&auto=format\&n=L_vQfA0JQEpeGUUo\&q=85\&s=130925a3ad390d68eebe1f1b5f120723)

2. Assign the **Workspace draft editor** role to users who should go through the approval process

3. By default, all roles except Workspace draft editor 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](https://docs.hightouch.com/workspace-management/approval-flows.md)

### Environments

> [!NOTE]
>
> Environments apply to **models and syncs only** ([rETL
> workflows](https://docs.hightouch.com/getting-started/concepts.md)). Customer Studio resources — such as
> audiences, destination rules, and sync templates — cannot be deployed between
> environments. For Customer Studio change management, use **Approval Flows**
> instead.

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](https://docs.hightouch.com/workspace-management/environments.md)

### 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](https://docs.hightouch.com/syncs/warehouse-sync-logs.md).

![Audit log](https://mintcdn.com/hightouch-3c037897/L_vQfA0JQEpeGUUo/images/workspace-management/governance/gov-audit-log.png?fit=max\&auto=format\&n=L_vQfA0JQEpeGUUo\&q=85\&s=37d41fe8cee8aeca9c7e1a8566957292)

See:

* [Audit logs](https://docs.hightouch.com/workspace-management/audit-logs.md)

### When to use this

Use review and change-management controls when multiple teams can affect production workflows, or when your organization needs more formal approval before activation.

## Choosing the right governance controls

Not every team needs every governance feature from day one.

A practical way to roll out governance is to start with the controls that match your organization's complexity.

### Smaller teams

Start with:

* Workspace structure
* User groups
* Roles

### Growing teams

Add:

* Subsets
* Spaces (if enabled for your workspace)
* Basic destination controls

### Larger or more regulated teams

Consider:

* Custom groups and scoped roles by team, region, or brand
* Subsets by region, brand, or business unit
* Spaces
* Destination Rules
* Audience Templates
* Sync Templates
* Approval Flows
* Environments (for rETL models and syncs only)
* Audit logs

The goal is not to add as many controls as possible. The goal is to give teams the access they need while reducing unnecessary risk.

## Recommended governance patterns

### If teams share customer data but work independently

Use:

* One shared workspace
* Roles for action-based access
* Subsets for data access
* Spaces for team-level visibility (if enabled for your workspace)

### If different regions or entities must be fully separate

Use:

* Separate workspaces
* Separate infrastructure or regional connections as needed

### If consent rules differ by channel

Use:

* Destination Rules
* Sync Templates

### If campaign changes should be reviewed before launch

Use:

* Approval Flows
* Environments (for rETL models and syncs only) for staging and production where needed

## Next steps

To put governance into practice, start with the feature docs for the controls you need:

* [Core concepts](https://docs.hightouch.com/workspace-management/overview.md)
* [User groups](https://docs.hightouch.com/workspace-management/user-management.md)
* [Roles](https://docs.hightouch.com/workspace-management/roles.md)
* [SSO and SCIM](https://docs.hightouch.com/workspace-management/sso.md)
* [Subsets](https://docs.hightouch.com/customer-studio/subsets.md)
* [Destination Rules](https://docs.hightouch.com/customer-studio/destination-rules.md)
* [Data masking](https://docs.hightouch.com/customer-studio/data-masking.md)
* [Audience Templates](https://docs.hightouch.com/customer-studio/templates.md#audience-templates)
* [Sync Templates](https://docs.hightouch.com/customer-studio/templates.md#sync-templates)
* [Approval flows](https://docs.hightouch.com/workspace-management/approval-flows.md)
* [Environments](https://docs.hightouch.com/workspace-management/environments.md)
* [Audit logs](https://docs.hightouch.com/workspace-management/audit-logs.md)
* [Folders and labels](https://docs.hightouch.com/workspace-management/folders-filters.md)
* Spaces — must be enabled by Hightouch