Configure Snowflake permissions for Zero Copy segmentation

Learn how to configure and verify the Snowflake permissions required to enable Zero Copy segmentation.

Zero Copy segmentation evaluates segments directly inside your Snowflake instance. To run segmentation securely, grant your segmentation role <role> a specific set of Snowflake permissions that allow the role to read source data from the Snowflake tables that sync with Reltio, create the tables and tasks it needs in a dedicated schema, and write segment results to a shared results table, all within that same Snowflake instance.

Apply these permissions only if you enable segmentation for your Zero Copy integration. If you use Zero Copy integration without segmentation, you don't need these permissions.

Prerequisites

Before you begin, make sure you have the following roles and resources.

Roles you need:


Role	Used for
`<role>`, your segmentation role	The role every permission in this procedure is granted to. This is the same role you created for your Zero Copy integration; segmentation adds permissions to this role rather than requiring a new role.
`SECURITYADMIN`, or a custom role with the `MANAGE GRANTS` permission	Runs every command in this procedure except granting `EXECUTE TASK ON ACCOUNT`, which requires `ACCOUNTADMIN` specifically.
`ACCOUNTADMIN`	Runs only the command that grants `EXECUTE TASK ON ACCOUNT`. Snowflake requires this specific role for that account-level permission.

Resources you need:

A warehouse and database identified for segmentation.
A dedicated, empty schema for segmentation, for example RELTIO_ZEROCOPY, so your segmentation role's access stays limited to the tables it creates and manages.

Throughout this procedure, replace <role> with your segmentation role, and replace <warehouse>, <db>, and <schema> with your warehouse, database, and schema names.

Complete the following procedure in a Snowflake SQL worksheet or the SnowSQL client.

To configure the Snowflake permissions required for segmentation

Log in to your Snowflake account.
In the navigation menu, click Worksheets > + Worksheet > SQL Worksheet to open a new SQL worksheet.
Grant your segmentation role, <role>, access to the warehouse, database, and schema used for segmentation.
```
GRANT USAGE ON WAREHOUSE <warehouse> TO ROLE <role>;
GRANT USAGE ON DATABASE <db> TO ROLE <role>;
GRANT USAGE ON SCHEMA <db>.<schema> TO ROLE <role>;
                    
```
These permissions let the segmentation role use compute resources, access the database, and operate within the schema.
Grant the segmentation role permission to create the tables, tasks, and procedures it needs for segment evaluation.
```
GRANT CREATE TASK ON SCHEMA <db>.<schema> TO ROLE <role>;
GRANT CREATE TABLE ON SCHEMA <db>.<schema> TO ROLE <role>;
GRANT CREATE PROCEDURE ON SCHEMA <db>.<schema> TO ROLE <role>;
                    
```
The segmentation role uses these permissions to create the shared results table in the next step, and the tasks and procedures it runs for each segment evaluation.
Using <role>, create the shared results table.
```
USE ROLE <role>;
CREATE TABLE IF NOT EXISTS <db>.<schema>.segment_results (
    segment_id VARCHAR(128) NOT NULL,
    entity_id  VARCHAR(128) NOT NULL
) CLUSTER BY (segment_id, entity_id);
                    
```
Segmentation writes every segment's results to this shared table and uses segment_id to separate the rows that belong to each segment. You create this table once, during initial setup, not per segment.
Grant the segmentation role permission to read the source tables it needs for evaluation.
```
GRANT SELECT ON ALL TABLES IN SCHEMA <db>.<schema> TO ROLE <role>;
GRANT SELECT ON FUTURE TABLES IN SCHEMA <db>.<schema> TO ROLE <role>;
                    
```
SELECT ON ALL TABLES covers the tables that already exist, such as entities and interactions. SELECT ON FUTURE TABLES extends that same access to tables created later. You don't need to grant this again when new tables appear.
Grant the segmentation role permission to write new results and remove stale rows.
```
GRANT INSERT ON ALL TABLES IN SCHEMA <db>.<schema> TO ROLE <role>;
GRANT INSERT ON FUTURE TABLES IN SCHEMA <db>.<schema> TO ROLE <role>;
GRANT DELETE ON TABLE <db>.<schema>.segment_results TO ROLE <role>;
GRANT DELETE ON TABLE <db>.<schema>."datatable" TO ROLE <role>;
                    
```
The insert permission lets the segmentation role write segment results. The delete permission on segment_results removes stale rows before writing updated results. The delete permission on datatable applies to Reltio's internal event processing table.
Using ACCOUNTADMIN, grant the segmentation role permission to execute the tasks segmentation creates.
```
USE ROLE ACCOUNTADMIN;
GRANT EXECUTE TASK ON ACCOUNT TO ROLE <role>;
                    
```
This grant lets Snowflake's task scheduler run tasks owned by the segmentation role. It doesn't grant access to any table data in your schema.

If you accidentally run this command while acting as the segmentation role instead of ACCOUNTADMIN, the permission appears valid in SHOW GRANTS TO ROLE <role>, but fails at runtime for dedicated service users. If this occurs, revoke the incorrect permission using the segmentation role, then reapply it using ACCOUNTADMIN.
To revoke,
```
USE ROLE <role>;
REVOKE EXECUTE TASK ON ACCOUNT FROM ROLE <role>;
USE ROLE ACCOUNTADMIN;
GRANT EXECUTE TASK ON ACCOUNT TO ROLE <role>;
```
Grant the segmentation role permission to apply tags to the tasks it creates.
```
GRANT APPLY ON ALL TAGS IN SCHEMA <db>.<schema> TO ROLE <role>;
```
Grant this permission, even if you don't plan to use tagging. Snowflake requires it before a role can apply any tag to a task, and it has no effect until you create a tag.
(Optional) Enable tagging for segmentation tasks.
Run this step only if you want to track and filter segmentation tasks by tag.
```
GRANT CREATE TAG ON SCHEMA <db>.<schema> TO ROLE <role>;                    
```
If you skip this step, Snowflake logs a warning stating that the tag couldn't be created or applied. You can ignore this warning; the segmentation task continues to run normally.

Result

The segmentation role reads source data, creates and runs the objects it needs for segment evaluation, and writes and cleans up results in segment_results, all within the boundaries of your dedicated schema.

Validation

Run the following commands to verify the permissions are in place and segmentation is ready to run.


Command	Expected result
`SHOW GRANTS TO ROLE <role>;`	The output lists every permission granted in this procedure.
`SHOW GRANTS ON SCHEMA <db>.<schema>;`	The output includes `USAGE`, `CREATE TASK`, `CREATE TABLE`, `CREATE PROCEDURE`, and `APPLY` on tags.
`SHOW GRANTS ON TABLE <db>.<schema>.segment_results;`	The output includes `SELECT`, `INSERT`, and `DELETE`.
`SHOW GRANTS ON ACCOUNT;`	The output shows `EXECUTE TASK` granted to `<role>` with `granted_by = ACCOUNTADMIN`.
`USE ROLE <role>; DELETE FROM <db>.<schema>."entities" WHERE 1=0;`	Fails with `SQL access control error: insufficient privileges to operate on table 'entities'`, confirming the segmentation role has no delete permission on protected tables.

Unify and manage your data

Configure Snowflake permissions for Zero Copy segmentation

Footer