Permissions

Data Integrity Suite
Product
Spatial_Analytics
Data_Integration
Data_Enrichment
Data_Governance
Precisely_Data_Integrity_Suite
geo_addressing_1
Data_Observability
Data_Quality
dis_core_foundation
Services
Spatial Analytics
Data Integration
Data Enrichment
Data Governance
Geo Addressing
Data Observability
Data Quality
Core Foundation
ft:title
Data Integrity Suite
ft:locale
en-US
PublicationType
pt_product_guide
copyrightfirst
2000
copyrightlast
2025

The Snowflake account requires a dedicated role with read-only access to extract metadata such as schemas, tables, views, procedures, and other relevant objects.

This privileges should be granted the necessary permissions to facilitate metadata import operations effectively.

Note: The metadata extraction is available only with Advanced Conectivity Bundle (ACB) entitlement.

  • Stored procedure definitions and associated lineage in Snowflake are available when:

    • It is defined with EXECUTE AS CALLER and the user with at least USAGE privilege on the procedure is used to harvest the metadata.
    • It is defined with EXECUTE AS OWNER (by default or explicitly) and the user with OWNERSHIP privilege on the procedure is used to harvest the metadata. To catalog the stored procedure definition and its associated lineage, either use a user account with the OWNERSHIP privilege or change the statement from EXECUTE AS OWNER to EXECUTE AS CALLER.

  • Required permissions on current objects: Grant privileges on existing objects so the bridge can read metadata:
-- Warehouse and database
grant usage on warehouse <warehouse_name>  to role <role_name>;
grant usage on database <database_name>  to role <role_name>;
-- Schema and object
grant usage on all schemas in database <database_name> to role <role_name>;
grant references on all tables in schema <schema_name> to role <role_name>;
grant references on all views in schema <schema_name> to role <role_name>;
grant references on all materialized views in schema <schema_name> to role <role_name>;
grant usage on all functions in schema <schema_name> to role <role_name>;
grant usage on all procedures in schema <schema_name> to role <role_name>;
grant usage on all sequences in schema <schema_name> to role <role_name>;
grant select on all streams in schema <schema_name> to role <role_name>;
grant monitor on all tasks in schema <schema_name> to role <role_name>;
grant usage on all stages in schema <schema_name> to role <role_name>;
grant monitor on pipe <pipe_name> to role <role_name>;
grant usage on external volume <external_volume_name> to <role_name>;
grant monitor on all dynamic tables in schema <schema_name> to <role_name>;
grant references on all semantic views in schema <schema_name> to role <role_name>;
grant database role SNOWFLAKE.OBJECT_VIEWER to role <role_name>;

  • Optional: future objects

Future objects are new objects created after the initial setup (for example, new tables or views). Granting permissions on future objects ensures the bridge automatically has access without repeated manual grants.

grant usage on future schemas in database <database_name> to role <role_name>;
grant references on future tables in schema <schema_name> to role <role_name>;
grant references on future views in schema <schema_name> to role <role_name>;
grant references on future materialized views in schema <schema_name> to role <role_name>;
grant usage on future functions in schema <schema_name> to role <role_name>;
grant usage on future procedures in schema <schema_name> to role <role_name>;
grant usage on future sequences in schema <schema_name> to role <role_name>;
grant select on future streams in schema <schema_name> to role <role_name>;
grant monitor on future tasks in schema <schema_name> to role <role_name>;
grant usage on future stages in schema <schema_name> to role <role_name>;
grant monitor on future pipes in schema <schema_name> to role <role_name>;
grant monitor on future dynamic tables in schema <schema_name> to role <role_name>;
grant references on future semantic views in schema <schema_name> to role <role_name>;
Note:
  • Assigning permission for future objects is recommended but not mandatory.
  • The permission requirements described here are subject to change depending on the database version, configuration, and future updates.