Snowflake RBAC

Overview

Snowflake RBAC lets Hightouch honor your Snowflake data governance when it runs in-app preview queries. When it's enabled, Hightouch maps your user groups to Snowflake roles and runs each user's previews under their resolved role, so Snowflake's masking policies, row access policies, and role grants apply exactly as they do in Snowflake itself.

Without it, every Hightouch warehouse query runs under the single service account configured on the source. With it, a marketer browsing an audience preview sees the same masked columns and filtered rows that Snowflake would show that marketer directly.

Scope

Snowflake RBAC governs the queries Hightouch runs on your behalf to show you data in the app:

• Model and rETL previews
• Audience previews and the audience member browser
• Trait previews
• Journey-condition previews
• Table browsing and ad-hoc counts
• Raw SQL previews

The following keep running under the service account, by design:

• Sync runs and materializations. These are pipeline operations, not per-user views of data.
• Audience size estimates and live counts. These are served from a shared cache, so they are not scoped to an individual user's role.
• Charts. Charts read pre-computed aggregates produced by syncs running under the service account. To keep governed values out of charts, exclude them from the models that feed your charts.

How it works

• Per source. RBAC is configured on each Snowflake source independently.
• Role mappings. You map a Hightouch user group to a Snowflake role. Each mapping has a priority.
• Default role. The role used for previews when no mapping matches the user. Saving a default role is what enables RBAC on the source.
• Resolution. For a given user, Hightouch uses the highest-priority mapping that matches any of the user's groups. If no mapping matches, it uses the default role.
• Role chip. Governed previews display a chip showing which role the query ran as and why (for example, Ran as MARKETER · via group mapping). The chip reflects the role verified at query time.

A workspace with RBAC available but no default role saved behaves exactly as it does today: all queries run under the service account.

Set up Snowflake

Create the roles you want to map and grant them to the Snowflake user your Hightouch source authenticates as. A role must be granted to that user, or Hightouch cannot run queries under it.

USE ROLE ACCOUNTADMIN;

-- Roles you will map to Hightouch user groups
CREATE ROLE IF NOT EXISTS ht_analyst;
CREATE ROLE IF NOT EXISTS ht_marketer;

-- Each mapped role needs the usage and read it requires
GRANT USAGE ON WAREHOUSE <warehouse>      TO ROLE ht_analyst;
GRANT USAGE ON WAREHOUSE <warehouse>      TO ROLE ht_marketer;
GRANT USAGE ON DATABASE <database>        TO ROLE ht_analyst;
GRANT USAGE ON DATABASE <database>        TO ROLE ht_marketer;
GRANT USAGE ON SCHEMA <database>.<schema> TO ROLE ht_analyst;
GRANT USAGE ON SCHEMA <database>.<schema> TO ROLE ht_marketer;
GRANT SELECT ON ALL TABLES IN SCHEMA <database>.<schema> TO ROLE ht_analyst;
GRANT SELECT ON ALL TABLES IN SCHEMA <database>.<schema> TO ROLE ht_marketer;

-- The mapped roles must be granted to the source's Snowflake user
GRANT ROLE ht_analyst  TO USER <hightouch_service_user>;
GRANT ROLE ht_marketer TO USER <hightouch_service_user>;

Define governance against the role names with Snowflake's own masking policies and row access policies, keyed on CURRENT_ROLE(). For example, a masking policy that returns raw email only for HT_ANALYST and masks it otherwise.

Set up role mappings in Hightouch

1. Open your Snowflake source and go to the Role Mapping tab.
2. Click Refresh roles. Hightouch discovers the roles currently granted to the source's Snowflake user and records them.
3. Set a default role. Saving the default role enables RBAC for this source.
4. Add mappings from user groups to roles, and drag to set their priority. The highest-priority matching mapping wins.

Keeping roles in sync

• Refresh is manual. Hightouch discovers roles when you click Refresh roles. There is no background polling.
• Revoked roles. If a mapped role is later revoked from the source's Snowflake user, it is marked unavailable at the next refresh and skipped: resolution falls through to the next available mapping in priority order, then to the default role. It never widens to the service account.
• No usable role. If none of a user's mapped roles is available and the default role is also unavailable, that user's previews are blocked until a role is restored or re-mapped, rather than falling back to the broader service account.
• Connection changes. If the source's connection identity (account, login user, or authentication) changes, all previews on the source are blocked until you refresh roles under the new identity. This prevents serving data under a governance context that no longer matches the connection.

Limitations

• Snowflake only. Role-based preview governance is available for Snowflake sources. Other warehouses are not supported.
• Previews only. As described in Scope, syncs, materializations, audience size, live counts, and charts run under the service account.
• Group-based mapping. Mappings are from Hightouch user groups to Snowflake roles. Per-user and identity-provider-driven mapping are not supported.