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.

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.

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.

Source

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

Configure and use models

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)

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

Configure and use audiences

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)

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 and Use Audiences) 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.

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.

The Draft and Approve grants are separate. If you want a user to publish changes without needing additional approval, assign both the Draft and Approve grants. (In practice, the user creates the draft and immediately self-approves it.)

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.

General

Source

Destination

Customer Studio

What happens if a user belongs to more than one group?

Users can belong to multiple groups within the same workspace, allowing them to inherit permissions from more than one role at a time.

This setup is common. When a user is part of multiple groups, they receive the combined permissions of all their group memberships, meaning that they can perform all actions permitted to members of any of those groups.

However, this does not allow them to “mix and match” permissions across groups. In other words, if one group can sync from source A to destination B, and another group can sync from source C to destination D, a user who belongs to both groups can sync from A to B and C to D—but not from A to D or C to B.

How do I prevent a user from seeing a resource?

In Hightouch, all resources in a workspace are intentionally visible to all workspace members; configuration details are not hidden. Access control determines who can create or modify resources, but it cannot make resources invisible. If you need to restrict visibility of sensitive resources for certain users, consider placing these resources in a separate workspace.

Assigning a role

Roles are always assigned to user groups, never to individual users.

By default, new groups don't have access to any workspaces. To grant access, navigate to Organization settings > Groups, select the group from the sidebar, and open the Workspaces tab. Use the Role dropdown to assign the appropriate access level for each workspace. You can select from built-in roles (e.g., “Workspace viewer”) or create a custom role for more fine-tuned control.

The Access column provides an overview of the group's permissions for each workspace, showing the actions they can take for each destination. While it gives a helpful summary, it doesn't display every possible grant or cover permissions related to other resource types.