Roles

Getting started

When a user group is given access to a workspace, they're assigned a role. This role defines what actions they can take with the workspace's resources. You can think of it as a “job description” that outlines which data sources and destinations the group is responsible for and what they're allowed to do with them.

Roles let you set up different levels of access, making it easy for teams to collaborate and tap into valuable customer data in your warehouse—all while ensuring privacy, security, and compliance.

Hightouch offers two types of roles:

Pre-built roles: Great for onboarding, these roles cover common access levels (like admin, editor, and viewer) and make it easy to set up your workspace right away.
Custom roles: As your organization grows, custom roles allow you to set fine-grained permissions that match each team's responsibilities. Custom roles are helpful for scaling your Hightouch workspace across multiple teams, regions, or brands.

We recommend starting with pre-built roles during onboarding. When you're ready to broaden access or tailor permissions for specific teams, you can easily switch to custom roles.

What role-based access control is (and isn't)

What it is

Role-based access control (RBAC) is a system that manages access to resources—such as syncs and models—according to a user's role within a workspace.

What it's not

RBAC is not a catch-all solution for data governance. While it manages access based on user roles, it doesn't enforce universal policies, such as redacting PII or ensuring that consent requirements are met.

Achieving quality and compliance at scale often requires governance that applies uniformly across all users, regardless of their roles in a workspace. To address these needs, Hightouch provides a broader suite of governance and collaboration features:

Destination rules determine which kinds of data can be delivered to specific destinations—such as ensuring only consented users are synced to email marketing tools.
Subsets let you divide your total addressable customer base into smaller segments, which is especially useful in workspaces that span multiple brands or regions.
Approval flows add an extra layer of quality control by requiring peer review for changes to syncs or models before they're published.
Staging environments provide a dedicated space to test syncs before going live, reducing the risk of errors in production.

Each of these features has its own unique purpose, though some may overlap with RBAC. For instance, you might want to restrict access to certain subsets or require approvals only for specific user groups. This overlap and how to manage it will be explored in the sections that follow.

As you read through this article, remember: you don't need to implement every governance feature in Hightouch—especially if you're just getting started. Many of these options are designed for large enterprises with complex brand structures and compliance requirements. If you have questions or need guidance on setting up your workspace, feel free to reach out—we're here to help!

Understanding access control in Hightouch

Resources in Hightouch are highly interconnected and abstracted, often in ways that aren't visible to users.

For example, syncing data from BigQuery to Salesforce might look like a single action, but it actually involves four distinct resources: the source (BigQuery), the model that pulls data from BigQuery, the destination (Salesforce), and the sync that moves data to Salesforce.

In some cases, resources are created individually by the user, as in the Hightouch Reverse ETL product. In other cases, they are auto-generated when users build constructs like “audiences” and “journeys” in Customer Studio, or “flows” in AI Decisioning. This abstraction is intentional because it allows users to focus on business and marketing goals without needing to manage the underlying data pipelines.

However, with this level of abstraction, dependencies multiply—and so does the need for a thoughtful access control strategy. Managing permissions for each model and sync would quickly become unmanageable, creating a labyrinth of settings that admins would need to continually update. That's why we believe a permissions system should reflect how admins actually think about governing data: by focusing on data visibility and data flow, rather than micromanaging every interaction.

Hightouch's permissions system is designed around sources and destinations. Models, syncs, and other resources don't have their own individual permissions; instead, they inherit permissions from their associated sources and destinations.

For example, to create a sync from BigQuery to Salesforce, users need permissions for both the source (BigQuery) and the destination (Salesforce). Think of it as needing two keys to open a valve: users must have explicit access to both ends of the pipeline to allow data to flow.

We think this approach helps simplify permissions management for admins, ensuring that data flows only where it's explicitly allowed. With two separate layers of approval for each sync, this design aims to make governance more manageable and to keep the permissions layer organized, clean, and auditable—even as resources and dependencies grow.

When setting up custom roles, keep these two questions in mind:

What kinds of customer data are these users permitted to access? For Reverse ETL, this is defined at the source level, while in Customer Studio, it can be set by parent model or subset.
Where can they send this data? This is always defined at the destination level.

Access to a source does not grant permission to sync its data to any destination, nor does access to a destination mean any data can be sent there. Permissions for both the source and destination are needed to create a sync.

The anatomy of a role

Each role in Hightouch is composed of four types of grants:

General grants: these are basic permissions covering actions like adding new sources or destinations to the workspace.
Source-level grants: these define how users can interact with each source, such as managing credentials, viewing row-level data, and creating models using the source.
Destination-level grants: these specify permitted actions for each destination, like creating syncs, triggering sync runs, setting up alerts, and managing credentials.
Customer Studio grants: these are specific to the Customer Studio product and function just like source-level grants, except they apply to parent models instead of the underlying source. These grants mainly control the types of audiences users can create and determine if users can view data about individual members of those audiences.

Reference list of individual grants

When configuring a custom role, you'll see a list of individual grants that can be toggled on or off. These grants are built around two key pillars of governance: managing data visibility and controlling data flow. Below, you'll find a breakdown of each grant, detailing its function and how it affects different features across the Hightouch app.

General

Can this role create new sources?

Enabling this grant allows a user to create new data sources of any type within the workspace. During setup, they can also assign permissions to other groups, specifying who should have access to the newly created source.

Can this role create new destinations?

Enabling this grant allows a user to create new destinations of any type within the workspace. During setup, they can also assign permissions to other groups, specifying who should have access to the newly created destination.

Workspace-level resources—such as folders, extensions, custom storage, and API keys—can only be configured by workspace admins.

Source

Source-level permissions are designed primarily for Reverse ETL use cases, where users need the flexibility to run custom SQL when pulling data from the source. If you're creating a role for marketers in Customer Studio, it's best to avoid enabling any source grants. Instead, use Customer Studio grants, which limit access to specific parent models and subsets, ensuring that marketers work within your pre-approved Customer Studio schema.

View source data

With this grant enabled, users can view row-level data from this source across the Hightouch app. This includes:

Previewing models
Viewing row-level data when testing rows during sync creation
Accessing row-level data in the debugger for historical sync runs

Primary keys and error messages are not classified as row-level data to preserve basic sync observability. If you choose not to assign this grant, avoid using columns with PII (like email or phone number) as primary keys, as these fields will be visible to all users across the app.

Configure models & syncs

When enabled, this grant allows users to:

Create, edit, or delete models that pull data from the source
Use these models for syncing (provided the user has permissions to sync data to destinations)

Users can only edit existing models if they can also edit all of the syncs that rely on that model.

Configure schema

Applicable only to workspaces with Customer Studio, this grant allows users to configure the schema layer for Customer Studio, including traits, destination rules, and subsets.

Manage source

With this grant enabled, users can edit the source configuration, which includes:

Updating connection details and credentials
Adjusting the sync engine choice
Setting source-level defaults for Warehouse Sync Logs

Destination

Trigger syncs

With this grant enabled, users can manually trigger sync runs in the Hightouch app. Note that it does not grant permission to modify the recurring schedule for a sync.

Configure syncs

This grant allows users to create, edit, or delete syncs that send data to the destination. It includes permission to set a schedule for the sync, but does not allow users to manually trigger sync runs.

Manage destination

Enabling this grant allows users to modify the destination's configuration, including:

Updating connection details and credentials
Configuring defaults for alert triggers and recipients

Customer Studio

These grants function similarly to source-level grants but are scoped to specific parent models within the Customer Studio schema.

View parent model data

Enabling this grant allows users to view row-level data from the parent model throughout the Hightouch app. This includes:

Previewing audiences to see row-level data for individual members
Viewing row-level data when testing rows during sync creation
Accessing row-level data in the debugger for historical sync runs

If a user has the Configure audiences & syncs grant but lacks the View parent model data grant, they can still preview audiences, but they'll be limited to aggregate counts and insights, without row-level data for each audience member.

Configure audiences & syncs

When enabled, this grant allows users to:

Create, edit, or delete audiences that pull data from the parent model
Use these audiences for syncing (provided the user has permissions to sync data to destinations)

Users can only edit existing audiences if they can also edit all of the syncs that rely on that audience.

Differences when subsets are enabled

Subsets is a data governance feature in Hightouch that allows you to break down a parent model into smaller segments, each with its own permissions. This approach helps your data team reuse a single Customer Studio schema across different brands, regions, and more—all while ensuring that marketing teams only have access to the customer data relevant to their slice of the business.

Subset permissions are especially useful if, for example, you want your EU-based marketing team to build audiences solely from EU customers. Likewise, you could restrict your email marketing team to using audiences consisting only of customers who have consented to receive marketing emails.

When subsets are enabled, you'll see a separate set of checkboxes that let you apply earlier grants (like View parent model data and Configure audiences & syncs) to specific subsets. The behavior of these checkboxes varies based on whether the subset category is marked as "required."

If the subset category is required, the user will only be able to configure and use audiences within the selected subset values. (If no values are checked, the user will not be able to configure or use any audiences at all.)
If the subset category is not required, the user can configure and use audiences with the selected subset categories, or without subsets altogether.

Differences when approval flows are enabled

Approval flows is a change management feature in Hightouch that adds an extra layer of peer review for changes to syncs or models before they're published. You can assign approval rights to specific user groups, and custom roles let you define detailed policies for each source and destination. For example, a marketer might be able to self-publish syncs to Google Ads but need approval to sync data to Salesforce.

When approval flows are enabled for a workspace, the Configure models & syncs grant is decomposed into two separate grants: Draft models & syncs and Approve models & syncs.

Draft models & syncs allows a user to create drafts for new models or syncs, or propose changes to existing ones. This grant doesn't allow users to delete published resources, but they can discard draft changes.
Approve models & syncs allows a user to review drafts and either approve or deny them. Once approved, the drafts are immediately published.

Together, these two grants provide the same functionality as the original Configure models & syncs grant.

Approval flows do not apply to audience creation in Customer Studio, as there is no concept of a draft audience. However, approval may be required to sync an audience to a destination.

The Draft and Approve grants are separate and do not overlap. To allow a user to publish changes without requiring approval, you need to assign both the Draft and Approve grants. (Under the hood, the user creates a draft and then immediately self-approves it.)

To approve a sync, a user needs the Approve grant for both the source and the destination.

Pre-built roles

We recommend starting with pre-built roles during onboarding. These roles cover the most common access levels like admin, editor, and viewer. Once you're settled in, you can switch to custom roles for more granular control over specific sources and destinations.

There are four pre-built roles.

Workspace admin includes all grants and is typically assigned to members of the data or IT team managing the workspace. Users belonging to the Organization admins group automatically inherit the Workspace admin role for all workspaces in the organization.
Workspace viewer functions as a spectator in the workspace. Users with this role can view resources, but they cannot see row-level data or create new resources. (This role is omitted from the reference tables below.)
Workspace editor has substantial autonomy in creating and editing syncs. They can set up new sources and destinations and create or edit syncs and models for any source or destination. However, workspace editors cannot delete or update configuration for existing sources and destinations.
Workspace draft editor can propose drafts and seek approval from another user. Draft editors cannot trigger syncs.

All built-in roles apply to all sources and destinations. If you want any source- or destination-specific controls, you need to use a custom role.