Required Snowflake Objects

Regardless of how your ALTR account is created, ALTR requires five Snowflake objects: a database, a stored procedure, a service user, a role, and a warehouse. If you create your account through Snowflake Marketplace, these objects are created for you. On the default manual path, you create the user and database yourself, and the stored procedure creates the role and warehouse.

Object	Marketplace Object Name	Default Manual Object Name
Database	`PC_ALTR_DB`	`PC_ALTR_DB`
Stored Procedure	`SETUP_ALTR_SERVICE_ACCOUNT` (placed in `PC_ALTR_DB` automatically)	`SETUP_ALTR_SERVICE_ACCOUNT` (placed in the database you create to house it)
User	`PC_ALTR_USER`	`ALTR_SERVICE_USER`
Role	`PC_ALTR_ROLE`	`ALTR_SERVICE_ROLE`
Warehouse	`PC_ALTR_WH`	`ALTR_SERVICE_WH`

These are the default, recommended object names – not required. Use the custom-object-name version of the setup stored procedure if you use different names – see Create a Service User.

Run the SETUP_ALTR_SERVICE_ACCOUNT stored procedure so the ALTR service user has the privileges it needs. See Create a Service User for the steps and when to re-run it, and Service User Privilege Requirements for the privileges it grants.

Snowflake Privilege Grants to Future Tables

The stored procedure grants privileges to your ALTR service role on current and future database, schema, and table objects.

Snowflake allows future grants at both the database level and the schema level; when a privilege is granted to a future object of the same type at both levels, the schema-level grant takes precedence and the database-level grant is ignored. ALTR sets its future-object privileges at the database level rather than the schema level, so the setup procedure doesn’t need to run again when new schemas or tables are added to an already-connected database. For example, the stored procedure uses:

GRANT SELECT ON FUTURE TABLES IN DATABASE "<DATABASE>";

instead of:

GRANT SELECT ON FUTURE TABLES IN SCHEMA "<SCHEMA>";

If your database operations require schema-level privileges granted to other roles on future tables in an ALTR-connected database, explicitly grant SELECT on future tables in that schema to the ALTR service role as well.

ALTR Objects for Catalog-Linked Databases

ALTR keeps the masking, Row Access Policy, and tokenization objects for a catalog-linked database in ALTR_DSAAS_DB, because a catalog-linked database can’t hold them. Each connected catalog-linked database gets its own schema there, named ALTR_DSAAS_CLD_ followed by the database name. ALTR creates the schema when you connect the database and drops it when you remove the data source.

ALTR converts the database name to uppercase and replaces any character other than a letter, digit, or underscore with an underscore. If that changes the name – for example, because it contains lowercase letters – or the result is too long for a Snowflake identifier, ALTR shortens it as needed and adds an underscore and an 8-character hash, so each database gets its own schema.

To create the schema, the service role needs USAGE and CREATE SCHEMA on ALTR_DSAAS_DB, which it has as the owner if it created ALTR_DSAAS_DB. See Service User Privilege Requirements.

Service User Authentication

Key-pair authentication is the only authentication method ALTR sets up for the ALTR service user. ALTR can’t create password authentication for a service user or switch one to it.

If you change credentials for your service user in Snowflake without also updating them in ALTR, ALTR will be unable to connect to Snowflake – existing masking and access control policies continue to function, but ALTR can’t define new policies or generate accurate query audit logs. If you need to use a different service user or role name to match your naming convention, follow the custom service user steps on Create a Service User.