Snowflake Data Clean Rooms: Installation details¶

ADMIN¶

This schema contains any tables or views needed for the administration of the application. You can use it to track application versions, patches, and deployments. Key details include:

• Version information (number)

• Patches applied (version, commands)

APP SCHEMA¶

This schema contains functions and procedures which are necessary to facilitate all the clean room flows. Key details include:

• Encrypt and decrypt functions.

• Clean room procedures that you use with the developer APIs and web app to create, install, and work with clean rooms.

TEMPLATES¶

This schema contains the standard SQL Jinja templates which can be used to run analyses in using the developer APIs or web app.

These pre-built templates offer ready-to-use SQL queries for secure data collaboration within Snowflake Data Clean Rooms. They leverage Jinja templating for customization, allowing you to tailor queries to specific data sharing scenarios.

ADMIN¶

This schema contains information necessary to operate certain clean room features associated with the account, such as:

• Using Cross-Cloud Auto-Fulfillment to collaborate across regions or cloud platforms.

• Clean room metadata updates needed to register clean rooms from developer APIs to the web app.

• Versioning of the current procedures associated with the functioning of the web app with the Snowflake account.

• Tasks and Streams that listen to changes in the set of clean room shares that are shared back from collaborators, and to enable/disable clean rooms as needed based on the changes.

CONSUMER/CONSUMER_INIT¶

This schema contains procedures necessary to operate clean room install or consumer features associated with the account, such as:

• Shared clean room listing details needed for requesting Cross-Cloud Auto-Fulfillment clean rooms.

• Features related to using join/column policies and registering a database in a clean room.

• Support for installing and editing a clean room, running analyses, and viewing templates that have been added.

ID_HUB¶

This schema contains procedures and intermediate tables associated with the identity hub.

INFORMATION_SCHEMA¶

Like all Snowflake databases, this database contains the INFORMATION_SCHEMA schema (“Data dictionary”), which consists of a set of system-defined views and table functions that provide extensive metadata information about the objects created in your account.

LIBRARY¶

This schema contains procedures necessary to enable clean room connectors and features which are applicable for both provider and consumers, such as:

• Setting up Ads connector procedures facilitating integration with ID hubs and external tables.

• Registering database procedures to control Cross-Cloud Auto-Fulfillment enablement or disablement.

• Applying patches, unregistering databases, and updating clean room records.

PROVIDER¶

This schema contains data or information related to activations (streams and procedures to facilitate provider activations), saved analysis reports, meta information related to connectors configured on the Snowflake Data Clean Rooms accounts, and clean room records created by the account.

PUBLIC¶

This schema contains the developer APIs that you and the web app use to create and manage clean rooms. It also contains intermediate datasets owned entirely by you that get saved to the PUBLIC schema during flows such as identity resolution. For example, the output tables from LiveRamp’s resolution and transcoding process are saved to the PUBLIC schema and joined onto the view that gets linked to the clean room by the web app.

This schema has the following tables:

• CLEANROOM_RECORD: This table includes the status of a clean room (created, deleted) along with the user and timestamp of the last update. If the update was done in the web app, the user is the service account user. If the update was done in Snowsight using the developer APIs, the user is the actual user who called the API. The clean room database name can be customized in this table.

• CONNECTOR_CONFIGURATION: This table is the list of configured connectors in the account.

• REPORTS: This table includes the list of reports saved by the consumer in the web app. Top-level results from standard reports are saved in the table.

• HORIZONTAL_ANALYSIS_<report ID>: Output of analyses executed with the SQL Query template and custom templateS executed in the web app.

The database has three shares that get created from it:

• SAMOOHA_INTERNAL_GOVERNANCE_SUMMARY SHARE_NAV2: This share contains views on the GOVERNACE_SUMMARY and ACTIVATION tables in the PUBLIC schema. This gets shared with any providers who have created clean rooms installed by this account, and is used to share governance information and provider activations back.

• SAMOOHA_INTERNAL_LOGS_SHARE_NAV2: This share is on the LOG_EVENTS table and is primarily used to share logs on how ID resolution procedures are progressing back to Snowflake, given they use third-party native apps. No PII or data is ever shared back, only the success/failure of the third-party app APIs used for transcoding/resolution.

• SAMOOHA_INTERNAL_PROVIDER_METADATA_NAV2: This share is on two tables, ADMIN.METADATA_UPDATE_REQUESTS, which is used for developer APIs to web app registration requests, and ADMIN.RESOURCE_MONITOR_USAGE, which is only used by managed accounts to log usage.