Feb 27, 2025 — Snowflake Data Clean Rooms release notes¶

UI loading improvements¶

UI load times have been improved in key user flows in clean room and analysis listing pages as well as when navigating across steps within the clean room creation and installation flows.

External and Apache Iceberg™ table support in SQL templates¶

Privacy policies used in the SQL template within the UI are now supported on external and Apache Iceberg tables. Users can now leverage these objects in scenarios where they would like to enable free-form querying on their data while enforcing necessary privacy protection on their datasets.

Data Clean Rooms available with data sharing terms¶

Previously, customers were required to accept our Provider and Consumer Terms to onboard and use Snowflake Data Clean Rooms. Now customers can onboard and use Snowflake Data Clean Rooms under our Customer-Controlled Data Sharing Functionality Terms, which are included within our standard Service terms. If these terms have not yet been accepted, please reach out to Snowflake Support to accept these terms.

Improvements to provider-linked views in the API¶

Previously, a provider linking a view using the developer APIs needed to explicitly grant reference usage to all underlying databases referenced by the view. Now reference usage grants are applied automatically to underlying referenced objects when linking a view. Please note that the underlying object must still be registered for usage in clean rooms.

Multi-template approval¶

Previously, providers could only approve one template at a time submitted by a consumer to be used in the clean room. With this release, providers can approve multiple templates in a single request with the provider.approve_multiple_template_requests procedure.

Change in UI form handling with custom templates¶

If you providing a custom web form, any UI elements that have a references field that returns column names auto-populated by Snowflake will now return properly P/C aliased column names. Values accessed in the template should either be processed by IDENTIFIER or the sqlsafe filter in the template, and should not be aliased explicitly in the template.

For example, the following two elements passed in to provider.add_ui_form_customizations use references to auto-populate column names into template variables reference_provider_join and reference_consumer_column:

  'reference_provider_join': {
    'display_name': 'Provider join column',
    'description': 'Which provider col do you want to join on',
    'references': ['PROVIDER_JOIN_POLICY'],
    'provider_parent_table_field': 'source_table',
    'type': 'dropdown'
  },
  'reference_consumer_column': {
    'display_name': 'Consumer join column',
    'description': 'Which consumer col do you want to join on',
    'references': ['CONSUMER_COLUMNS'],
    'consumer_parent_table_field': 'my_table',
    'type': 'dropdown'
  }

Previously a custom template would have needed to qualify these values with p. or c. as shown here:

SELECT COUNT(*) AS cnt_agg FROM identifier({{ source_table[0] }}) AS P
  JOIN IDENTIFIER ({{ my_table[0] }}) AS C
  ON p.{{ reference_provider_join | sqlsafe }} = c.{{ reference_consumer_join | sqlsafe }};

With this change you should omit the p. and c. qualifiers from the template, as they will be provided directly to the variable:

SELECT COUNT(*) AS cnt_agg FROM identifier({{ source_table[0] }}) AS P
  JOIN IDENTIFIER ({{ my_table[0] }}) AS C
  ON {{ reference_provider_join | sqlsafe }} = {{ reference_consumer_join | sqlsafe }};