Basic multi-party collaboration

Introduction

This topic walks through the steps to create a basic multi-party collaboration. It demonstrates how to register templates and data offerings, how to add data to the initial version of a collaboration, and how collaborators can add resources after the collaboration is created. It also demonstrates how to run queries using templates and data resources in the collaboration.

Basic clean room collaboration workflow

Here is a basic multi-party clean room collaboration scenario:

  1. The collaboration owner registers any templates or data offerings that they want to appear in the initial configuration of the collaboration.

  2. The owner optionally asks any intended collaborators to register templates or data offerings that they want to appear in the initial configuration of the collaboration. Collaborators then give the resource IDs of the registered items to the owner.

  3. The owner creates a collaboration. The collaboration is defined by a collaboration YAML spec that lists the collaborators, their collaboration roles, and all resources that should be present in the initial version of the collaboration.

    • When a collaboration is created, the set of collaborators and their collaboration roles is fixed.

    • Additional resources can be added by collaborators after the collaboration is created, if their collaboration role permits it.

    • If your collaboration shares data with users in other cloud hosting regions, the sharer must enable Cross-Cloud Auto-Fulfillment on their account.

  4. Collaborators review and join the collaboration.

  5. Collaborators can then optionally link additional resources to the collaboration, such as templates and data offerings, depending on their collaboration roles. Additional resources can be added to a collaboration at any time.

  6. Analysis runners can run any templates assigned to them in the collaboration, using any data available to them in the collaboration. The analysis runner bears the cost of the analysis. Templates can be designed either to return query results in the response or to activate results to the caller or another collaborator.

The following sections describe the details of each of these steps.

Create a collaboration

To create a collaboration, you design a collaboration spec that defines all the collaborators and their collaboration roles.

If you want to make resources available in a collaboration as soon as it is created, the collaboration owner registers and links those resources before creating the collaboration, and includes the resource IDs in the collaboration spec.

If the owner expects to use resources from collaborators, the owner can also prompt those users to register their resources and give the owner the resource IDs to include in the collaboration spec. The owner also indicates in the collaboration spec where no resources are linked now, but can be linked in the future.

The owner then calls INITIALIZE to begin creating the collaboration. By default, INITIALIZE also automatically joins the owner to the collaboration. This is an asynchronous process, so the owner must call GET_STATUS until the status is JOINED.

The following snippet demonstrates creating and joining a collaboration.

 1  CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.INITIALIZE(
 2    $$
 3    api_version: 2.0.0
 4    spec_type: collaboration
 5    name: my_first_collaboration
 6    owner: alice
 7    collaborator_identifier_aliases:
 8      alice: example_com.acct_abc
 9      bob: another_example.acct_xyz
10    analysis_runners:
11      bob:
12        data_providers:
13          alice:
14            data_offerings: [] -- alice has not provided data to bob, but can do so in the future.
15          bob:
16            data_offerings: [customers_v1]  -- bob has registered a data offering and made it available to himself.
17        templates: []   -- No templates available yet for bob.
18      alice:
19        data_providers:
20          alice:
21            data_offerings: []
22          bob:
23            data_offerings: []
24        templates: []
25    $$,
26    'APP_WH'            -- Use this warehouse for initialization.
27  );                    --  XSMALL or SMALL warehouses are recommended for initialization.
28  SET collaboration_name = 'my_first_collaboration';
29
30  -- INITIALIZE automatically joins the owner. Check status until JOINED.
31  CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.GET_STATUS($collaboration_name);
32
33  -- Collaboration is visible here when it's joined.
34  CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.VIEW_COLLABORATIONS();

Notes on the script:

  • The collaboration consists of two collaborators, with the aliases alice and bob. You can use a full data-sharing ID anywhere you use an alias, but that is much less user-friendly.

  • alice is the owner.

  • Both alice and bob are analysis runners.

  • Both alice and bob are data providers to each other.

  • If you are a data provider, you must include the data_offerings field. This field can be populated or empty, indicating that there are no data offerings now, but they can be added later.

  • alice isn’t providing data to bob or herself, but can do so later (lines 14, 22).

  • bob has already registered a data offering, and provided it to himself in the initial collaboration (line 16).

  • bob isn’t providing data to alice, but can do so later (line 24).

  • Neither alice nor bob has templates available yet, but they can be assigned later (lines 18, 25). Note that the templates field is optional for an analysis runner. If you omit this field during initialization, collaborators can still assign templates to this analysis runner later.

Review and join a collaboration

You must join a collaboration to share resources and run analyses in the collaboration.

  • The creator joins automatically when calling INITIALIZE if auto_join_warehouse is provided. If auto_join_warehouse isn’t provided, the creator calls JOIN after INITIALIZE is complete.

  • Non-creators call REVIEW, and then JOIN.

    • REVIEW returns an overview of the collaboration and its resources. You can call REVIEW only once.

    • JOIN installs the collaboration clean room in your account and joins the collaboration.

Both INITIALIZE and JOIN are asynchronous procedures that take several minutes to complete. You must call GET_STATUS to see when each step is complete.

Important

If your account’s cloud hosting region is different from the collaboration owner’s, REVIEW triggers additional asynchronous setup steps. Call REVIEW repeatedly until it returns a successful response, indicating that setup is complete.

Joining is an asynchronous process; call GET_STATUS to see when your status is listed as JOINED.

Run an analysis

If you have the analysis runner role in a collaboration, you can run analyses against data sources shared with you in the collaboration.

Collaborations support two types of queries:

  • Template analyses. These queries run a template (a templated JinjaSQL statement) linked into the collaboration. Templates can be either analysis templates, which return results immediately to you, or activation templates, which save results to the Snowflake account of a designated participant.

  • Free-form SQL queries. If allowed by a data provider, you can access specified data offerings using SQL when signed in with your collaborator credentials. You run SQL queries directly, without calling a Collaboration API procedure, by accessing the fully qualified view name exposed by the collaboration.

The analysis runner bears the cost of running an analysis.

The collaboration specification determines whether you can run a template, activate results, or run free-form SQL queries. Your capabilities, as well as the data and templates available for you to use, are described in the collaboration specification.

Note

Columns from the data sources might have new names when exposed to the template or user. See Source column renaming to learn how and when source columns are renamed. Templates and user-provided arguments (such as a join column name) must use the final name, not the original name, if the column is renamed.

Learn more about all these analysis types in the following sections.

Run an analysis from a template

To run an analysis from a template, view the list of templates that you can run, view the list of data offerings that you can use, then call RUN with your values either as individual parameters or as an analysis specification in YAML format.

Tables that you pass into the source_tables field in the run configuration populate the source_table parameter in the template. The template’s my_table parameter is not populated or used unless you are using Snowflake Standard Edition with your own data.

Note

Resource installation is asynchronous. If a template was just installed, it can take a short while before it is available to run. If the template includes a code bundle, it can take additional time before the template is available. See how to determine when a code bundle is available.

The following example lists data offerings and templates that the user can access, then runs an analysis using the sales_join_template template (which is assumed to be listed by VIEW_TEMPLATES), passing in five named arguments to the template.

-- See which data offerings are available.
CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.VIEW_DATA_OFFERINGS($collaboration_name);

-- See which templates you can run.
CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.VIEW_TEMPLATES($collaboration_name);

-- Pass in the arguments in analysis YAML format.
CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.RUN(
  $collaboration_name,
  $$
    api_version: 2.0.0
    spec_type: analysis
    name: My_analysis
    description: Sales results Q2 2025
    template: sales_join_template

    template_configuration:
      view_mappings:
        source_tables:
          -  user1_alias.data_offering_v1.table_1
          -  user2_alias.another_data_offering_v1.table_2
      arguments:                                            -- The template defines conv_purchase_id and the other four arguments.
         conv_purchase_id: PURCHASE_ID                      -- You must examine a template to see which arguments it supports.
         conv_purchase_amount: PURCHASE_AMOUNT
         publisher_impression_id: IMPRESSION_ID
         publisher_campaign_name: CAMPAIGN_NAME
         publisher_device_type: DEVICE_TYPE
  $$ );

Enable and run free-form SQL queries on your data

A data provider can grant analysis runner permission to run arbitrary SQL queries against their data offerings. This means that the analysis runner can run an arbitrary SQL query directly against the data offering, rather than calling a template.

To learn more about free-form SQL queries, see Free-form SQL queries.

Run an analysis with your own data when you use Standard Edition

If you use Standard Edition, you can run an analysis in the standard way. However, you can’t link data into the collaboration to share with other users. The only way to pass your own datasets into a template is to use the technique described here.

To use your own data in a collaboration on Snowflake Standard Edition:

  1. Register your data offering by calling REGISTER_DATA_OFFERING.

  2. Call LINK_LOCAL_DATA_OFFERING to link your data into the collaboration for you to use. No other collaborators can see or access data linked locally.

  3. Use the data offering ID when you call RUN.

  • If you are using the parameterized version of RUN, pass your data offering IDs to the local_template_view_names parameter

  • If you are using the YAML version of RUN, provide your data offering IDs in the local_view_mappings.my_tables stanza of the request

  • If you are using the parameterized version of RUN, pass your data-offering IDs to the local_template_view_names parameter.

Tip

local_template_view_names and local_view_mappings.my_tables populate the my_table parameter in the template.

The following example shows how to run a template using the YAML format version of the run procedure. This example includes the my_tables field, which is populated by calling LINK_LOCAL_DATA_OFFERING.

-- See what data offerings are available. Your own local data will be listed here as well.
CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.VIEW_DATA_OFFERINGS($collaboration_name);

-- Pass in the arguments in analysis YAML format.
CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.COLLABORATION.RUN(
  $collaboration_name,
  $$
    api_version: 2.0.0
    spec_type: analysis
    name: my_analysis
    description: Cross-purchase results for Q4 2025
    template: mytemplate_v1

    template_configuration:
      view_mappings:
        source_tables:
          - ADVERTISER1.ADVERTISER_DATA_V1.CUSTOMERS
          - PUBLISHER.ADVERTISER_DATA_V1.CUSTOMERS
      local_view_mappings:
        my_tables:
          - PARTNER.MY_DATA_V1.MY_CUSTOMERS # Populate my_table array with my own table.
      arguments:  # Template arguments, as name: value pairs
         conv_purchase_id: PURCHASE_ID
         conv_purchase_amount: PURCHASE_AMOUNT
         publisher_impression_id: IMPRESSION_ID
         publisher_campaign_name: CAMPAIGN_NAME
         publisher_device_type: DEVICE_TYPE
  $$ );

Activate results

If the data provider and the collaboration spec allow it, you can save analysis results to your own Snowflake account, or the Snowflake account of a designated collaborator. A template either activates results or returns results immediately, not both.

To learn more about activation, see Activating query results.

Leave or delete a collaboration

  • Non-owners leave a collaboration by calling LEAVE. Any data offerings they have provided will be removed from the collaboration. You can’t rejoin a collaboration after leaving it.

  • Collaboration owners can’t leave a collaboration because ownership can’t be transferred. A collaboration owner can drop a collaboration for all collaborators by calling TEARDOWN.

Both processes are asynchronous. You must call GET_STATUS to monitor the status, and call LEAVE or TEARDOWN again when GET_STATUS shows the status as LOCAL_DROP_PENDING.

Examples

The following SQL examples demonstrate how to create and run a basic collaboration:

Two-party collaboration example

The following example demonstrates a two-party collaboration, where one party (named “alice”) is the collaboration creator, a data provider for herself and “bob”, and an analysis runner. “bob” is a data provider for himself and “alice”, and is also an analysis runner.

The example demonstrates the following actions:

  • Creating a collaboration.

  • Registering templates and data offerings.

  • Linking a template and data offering at collaboration creation time.

  • Joining a collaboration.

  • Linking additional resources to an existing collaboration.

  • Running an analysis.

To run this example, you must have two separate accounts with Snowflake Data Clean Rooms installed.

You can either download the files and upload them to your Snowflake account, or copy and paste the example code into worksheets in two separate accounts by using Snowsight.

Download the source SQL files, then upload them into two separate accounts that have Snowflake Data Clean Rooms installed:

Single-party collaboration example

This example demonstrates how to create and use a collaboration if you have only a single account for testing.

The example demonstrates creating a collaboration with a data offering and a template, then adding another data offering and template after the collaboration is created, and running analyses.

You can either download the file and upload it to your Snowflake account, or copy and paste the example code into a worksheet by using Snowsight.

Download the source SQL file, then upload it into a Snowflake account that has Snowflake Data Clean Rooms installed: